[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