[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf

Nick Kledzik kledzik at apple.com
Tue Feb 3 13:50:24 PST 2015


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




> 
> 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 DYLD_LIBRARY_PATH=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).





More information about the llvm-dev mailing list