[cfe-dev] [libcxx] build system questions

Michael Spencer bigcheesegs at gmail.com
Thu Dec 9 16:11:26 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

Attached is a patch that adds a sane CMake build and changes to
compile the code on Linux. The buildit script still works, but I don't
have access to a Darwin box to make sure testit and non-CMake-lit
still work. The only thing that's missing for Darwin CMake support is
the linker flags.

It also has a check target that runs the tests. 85% currently pass on
Linux with gcc 4.4.5. Most of the failures are due to locale not being
implemented, however, some seem unrelated.

- Michael Spencer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-cmake.patch
Type: application/octet-stream
Size: 36335 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101209/8272ea7b/attachment.obj>


More information about the cfe-dev mailing list