[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf (original) (raw)
Jack Howarth howarth.mailing.lists at gmail.com
Tue Feb 3 14:38:22 PST 2015
- Previous message: [LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
- Next message: [LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Feb 3, 2015 at 4:50 PM, Nick Kledzik <kledzik at apple.com> wrote:
On Feb 3, 2015, at 1:40 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
On 2015 Feb 3, at 13:26, Chris Bieneman <beanz at apple.com> wrote:
On Feb 3, 2015, at 1:06 PM, Jonathan Roelofs <jroelofs.lists at gmail.com> wrote:
On 2/3/15 12:08 PM, Chris Bieneman wrote: Other issues not tracked by bugs: * CMake builds for libc++? Can you elaborate... what do you mean by this? AFAIK this already works. Duncan made a comment on IRC about being libc++, but I’m not aware of what the specific issues were (hence the ?). -Chris +kledzik and bogner, who looked into this last. Duncan was concerned about libc++ on darwin. The problem was/is that the shipping Apple libc++.dylib did not use CMake (or the previous buildit script). It used its own Xcode project which passed a bunch of special linker flags. Building libc++ for darwin without the special flags produced a dylib that only partially worked. I have not recently tried to build libc++ for darwin from the LLVM repository. So, I don’t know if anyone has updated CMake files for libcxx to build something that works on darwin. -Nick
Nick, David Fang's packaging of the llvm 3.5.1 release for the fink project uses a cmake build of libc++ (as did the prior llvm 3.4.2 packaging). The libc++ changes are at…
but has some changes for support ppc builds and earlier darwin releases mixed in the patch. Jack
I don't remember quite what the issue is; perhaps Nick or Justin knows. I remember the repro though: 1. Complete a CMake build of clang+libcxx+compiler-rt. 2. Add DYLDLIBRARYPATH=path/to/lib to the environment (so that ld64 finds the just-built libLTO.dylib). 3. Everything, including
/bin/ls
IIRC, crashes, since the just-built libcxx.dylib doesn't "work". I work around this by not checking out libcxx in my CMake source trees (at least, not when I'm using LTO).
LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
- Previous message: [LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
- Next message: [LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]