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

Nick Kledzik
Tue, 03 Feb 2015 21:50:24 -0000

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