[cfe-dev] [libcxx] build system questions

Michael Spencer bigcheesegs at gmail.com
Wed Dec 8 11:08:33 PST 2010


On Wed, Dec 8, 2010 at 1:31 PM, Howard Hinnant <hhinnant at apple.com> wrote:
> On Dec 8, 2010, at 12:00 AM, Michael Spencer wrote:
>
>> On Tue, Dec 7, 2010 at 7:55 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>>> On Dec 7, 2010, at 7:49 PM, Michael Spencer wrote:
>>>
>>>> On Mon, Dec 6, 2010 at 9:06 AM, Howard Hinnant <hhinnant at apple.com> wrote:
>>>>> I think we should start out with a simple question:  What problem are we attempting to solve?
>>>>>
>>>>> -Howard
>>>>
>>>> If we want Windows support (which I do :P), CMake is the way to go.
>>>> I'm willing to do it, targeting POSIX-like platforms for now, as doing
>>>> a Windows port is a much larger project. It's also possible to do it
>>>> without requiring explicit source lists, even though there aren't that
>>>> many to begin with.
>>>
>>> Windows support seems motivating to me.  The build system will probably be the easy part.  locale support will be more challenging.  Another challenging part may be the low-level stuff such as type_info and exception_ptr.
>>>
>>> -Howard
>>
>> locale will be a lot of work, but not too hard. type_info should be
>> easy for clang, but hard for MSVC (if we even plan to support MSVC).
>> I'm afraid to look at exception_ptr :P. LLVM/Clang can't even do
>> exceptions on Windows currently.
>>
>> I've attached a very rough patch for Linux CMake support. It has a few
>> hard coded paths for my system which will need to be configured by
>> CMake instead. It compiles with both g++ and clang++, however, the lit
>> tests only work with g++ because clang++ doesn't understand
>> -nodefaultlibs.
>>
>> I just finished running all the tests. 2506 out of 4217 passed (~60%).
>> Most failures are due to undefined references, and the rest are due to
>> -fno_exceptions or -fno-rtti which I had to set because
>> __gxx_personality_v0 is part of libstdc++ (I also set
>> _LIBCXX_NO_{EXCEPTIONS,RTTI}, but it doesn't always seem to be
>> honored).
>>
>> TODO:
>> * Fix RPATH for shared libraries. I gave up and made it static.
>> * Add support for host and target triples, and auto-select host.
>> * Support Darwin
>> * Add CMake options for all the features.
>> * Configure the lit test config for the build or install dir
>> * Make clang honor -nodefaultlibs
>> * Figure out what libs are needed on Linux.
>> * Add "make check"
>>
>> - Michael Spencer
>> <really-hacky-cmake.patch>
>
> I've reviewed this patch.  Thanks for working on this.  I think it is premature to check it in at this point (with bigcheese and all :-)).  However I can see something like this coexisting with the current build system.  And I think getting libc++ to work with clang/Windows is a very good goal.
>
> I'm also going to be working on modifying libc++ to run on top of gcc's libsupc++.  Perhaps this will help the clang/Windows port?
>
> -Howard

I agree that it's not ready. I'm currently working on getting it to a
usable state. One thing that will be an issue with keeping the current
system is __config. I'm currently rewriting it using the CMake config
checks system, although it would be simple to just have the build dir
have higher include precedence in the CMake build so it doesn't select
the hard coded one.

Adding libsupc++ support will help with Windows via MinGW.

Thanks for the support. I'll send a real patch for CMake support once
it's sane :P.

- Michael Spencer




More information about the cfe-dev mailing list