search for: aw1621107

...e it build via home-brew, and I don’t think we should be taking an effectively untested patch that doesn’t actually enable you to build. You may want to take up this issue with whomever maintains the home-brew package you’re trying to build. -Chris > On Sep 22, 2015, at 2:50 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > Doesn't look like it's set when that command runs. > > The env during the build looks something like the first one here: > https://gist.github.com/aw1621107/3e0b5a36d028f648d7a0 <https://gist.github.com/aw1621107/3e0b5a36d028f648d7a0> >...

The behavior here is consistent with setting SDKROOT in the environment to an OS X SDK. -Chris > On Sep 22, 2015, at 2:28 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > Logs + commands added to the earlier gist. > > Only thing different from a plain trunk build is adding -Wl,-v and -Wl,-t to the > iossim link flags. > >> On Sep 22, 2015, at 5:17 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at app...

...ou please provide the full error and information about the failure you saw without your patch? Since you couldn’t build before the patch, and you can’t build with the patch. I suspect there is an underlying issue which isn’t being addressed. -Chris > On Sep 22, 2015, at 2:02 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > Whoops. Forgot to include what happened before the patch. > > Without it, my build fails earlier with something along the lines of "Building for > iOS simulator, but linking against file (libc++.dylib) built for OS X (x86_64)". > The linker...

.../ubsan (was _wordexp > in the past, now is _sigaltstack$UNIX2003"i), or ranlib getting bad input while > working on native tablegen (archive extends past end of file, no such file are > the ones I remember) > > Full commands + partial logs here: > https://gist.github.com/aw1621107/86fec1e1fa9cc66bbf4d <https://gist.github.com/aw1621107/86fec1e1fa9cc66bbf4d> > > This was built on OS X 10.11, Xcode 7.1 using the following homebrew command > and formula: > > brew install llvm --with-clang --with-sanitizers --HEAD --debug --verbose > https://github....

On Tue, Sep 22, 2015 at 01:04:27PM -0700, Chris Bieneman via llvm-dev wrote: > This does not sound right. -isysroot specified during linking should be passing through the sys root to the linker. No? It should just be dropped. Joerg

Alright, this version works for me. Anything else that needs to be done? -Alex > On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..cb06450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@ function(add_public_tablegen_target target) > s...

...urn into a game of whack-a-bug. I would guess having each > tablegen build in its own directory would solve this and any related bugs, but > that's a change that would take a bit more time. > > -Alex > <llvmtablegen.patch> >> On Oct 8, 2015, at 6:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: >> >> Alright, this version works for me. >> >> Anything else that needs to be done? >> >> -Alex >> >>> On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: >>> >>> diff --git a/...

...get and command won’t get added unless needed and CMake won’t spew dev warnings. Adding a target with a nonexistent dependency makes CMake dump a bunch of developer warnings. Other than that this looks good. Does it resolve the issue for you? -Chris > On Oct 7, 2015, at 4:09 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..b24197b 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,13 @@ function(add_public_tablegen_target target) > s...

...Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Probably should have checked earlier... Do patches go directly to llvm-commits for review instead of getting reviewed here first? > > ccing llvm-commits too in case >> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote: >> >> Alright, got something thrown together. Here it is inline (also attached if that's more convenient): >> >> diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake >> index 452a728..be6729d 100644 >> --- a/cmake...

...was scrubbed... Name: TableGen.cmake.patch Type: application/octet-stream Size: 1208 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151004/a7ba00bb/attachment.obj> -------------- next part -------------- > On Sep 28, 2015, at 5:19 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > That sounds much more reasonable than more directories. I'll see if I can't hack something together... > > I still think you have a point; I would have expected cmake to catch that dependency. Strange thing is that just that library had an independe...

I'm looking at an issue for Homebrew (OS X package manager) where the compiled libc++ tries to load libc++abi at "@rpath/libc++abi.1.dylib", resulting in a dyld error. The issue can be found at https://github.com/Homebrew/homebrew/issues/47149 From what I can tell, this is a result of lines 561-564 of the CMakeLists.txt in the main LLVM repo: set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)

+llvm-commits (correct list) On Tue, Sep 22, 2015 at 12:32 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Could you describe the build failures you see after applying this patch? > I'll let Chris judge if adding -Wl,-syslibroot makes sense for iossim, or > that problem should be solved differently. > > On Tue, Sep 22, 2015 at 9:37 AM, Alex Wang via llvm-dev <

Hello backend devs, Been working on a parallelization bug in the cmake configs, where parallel makefile builds of llvm with clang and native tablegen would usually break during linking in either either the clang_tblgen or llvm_tblgen targets. Looking at the cmake command that generates the tablegen makefile commands (I think) (cmake/modules/TableGen.cmake:113-117):

> On Dec 9, 2015, at 1:56 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Not sure, but my guess is that the ocaml documents targets aren’t being included in the ALL target, which is resulting in them not being built before the install action. I think you're right. Running "make ocaml_doc" then rerunning "make install" completed the