libc++ now mostly works on FreeBSD with libcxxrt and this patch applied to the base system:
http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110920/e666632c/xlocale-0001.obj
Summary of tests on FreeBSD:
****************************************************
Results for /root/libcxx/test:
using FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
with -std=c++0x -stdlib=libc++ -I/root/libcxx/include -L/root/libcxx/build/lib
----------------------------------------------------
sections without tests : 1
sections with failures : 48
sections without failures: 1015
+ ----
total number of sections : 1064
----------------------------------------------------
number of tests failed : 145
number of tests passed : 4179
+ ----
total number of tests : 4324
****************************************************
(Many due to this clang version not supporting C++ atomics)
More fixes to follow...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@140245 91177308-0d34-0410-b5e6-96231b3b80d8
traits.
To the best of my knowledge, this will not break the ABI for Apple.
However, it does introduce three publicly visible (although with
reserved name) functions that will fail to link against the just-shipped
Apple version of libc++. Since they are not used in any inline
functions, no actual breakage should occur.
If Howard doesn't want to put undefined functions (even internal ones)
into a header, they could be surrounded by additional conditional
compilation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@134781 91177308-0d34-0410-b5e6-96231b3b80d8
