[cfe-dev] [PATCH] Added support to libc++ for GCC 4.3, GCC 4.5, and most recent head of Clang.

[Jesse Towner]

No problem. I also just compiled it using the latest head of GCC 4.6 on
Ubuntu as well, so that fix to make it work with GCC's nullptr turned out to
work fine. Finally figured out how to get libc++ all compiled and linked
together on OS X too (I was missing the libc++abi package that was pushed
out the list a while back), so now I'm running the test suite, going to diff
the test output after applying the patch to see how it works with GCC 4.2.1,
then going to try the latest Clang version on OS X too, not sure how that's
going to go.

- Jesse Towner

On Thu, Aug 5, 2010 at 7:17 AM, Clark Gaebel <cg.wowus.cg at gmail.com> wrote:

>  Thank you so much for this. Using clang with gcc 4.5.0 headers has been a
> real pain point for me.
>
>
> On 08/05/10 05:41, Jesse Towner wrote:
>
> Hey folks, here's a patch I made that gets libc++ compiling with GCC
> 4.3, GCC 4.5 and the latest version of Clang.
>
> Altogether, I was able to compile it with GCC 4.3.4, GCC 4.4.3, GCC
> 4.5.1 and latest Clang/LLVM 2.8 head on Ubuntu, with or without
> -std=c++0x. It also compiles with GCC 4.1, but due to some ABI issues
> with libstdc++, the shared library won't fully link.
>
> I haven't run the test suite yet due to the missing locales
> implementation on Linux, although most of the test cases appear to
> compile properly. There's still the occasional warning message here
> and there, and there's naturally a lot with -Wall -Wextra.
>
> Change list:
>
> - Better C++0x feature detection for both GCC and Clang (using Clang's
> __has__feature builtin preprocessor macro). Added explicit detection
> for defaulted and deleted functions.
> - Fix for Clang compilation error: Changed __config header to
> recognize Clang's support for builtin unicode character types char16_t
> and char32_t.
> - Fixes for GCC 4.3: Moved a lot of the GCC 4.3 C++0x feature support
> up to 4.4 for now in __config header, as although they exist in 4.3,
> various parts of libc++ assumed that they were fully implemented or
> implied the existence of other C++0x features. Also fine-tuned some
> preprocessor conditional checks in iterator, memory, thread,
> type_traits and utility headers to account for this. It'd probably be
> possible to rewrite a bunch of the offending areas (things that use
> variadic templates and auto/decltype) so that they could work in 4.3.
> - Fix for GCC 4.5 compilation error: Added implicit cast to void* in
> nullptr_t implementation to handle stricter template argument type
> matching in this compiler.
> - Fix for GCC 4.5 compilation error: Changed both std::move and
> std::forward C++0x-specific implementations to explicitly cast the
> object to an r-value reference type as GCC 4.5 implements the new
> wording for move semantics and rvalue references
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html).
> This didn't introduce warning messages in any of the other compilers I
> tested with, so not sure what compiler was originally causing the
> issues here.
> - Preliminary fix for GCC 4.6: Changed libc++ to use GCC 4.6's builtin
> nullptr keyword.
>
> Cheers,
>
> Jesse Towner
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> --
> Regards,
> -Clark
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100805/b9ccb4ac/attachment.html>