Hi, I've just imported libc++[1] and libcxxrt[2] to head. libc++ is UUIC licensed, libcxxrt is 2-clause BSDL. The former implements the C++ standard template library, and provides all of the programmer-visible parts. The latter provides an implementation of the ARM and Itanium ABI specifications providing the dynamic parts of the language (RTTI, exceptions, and so on). This combination working out-of-tree and passing almost all of the test suite (the failing parts are related to missing C1x functionality in libc and missing C++11 / C1x atomic intrinsics in clang). The goal of this is to have a working, permissively licensed, C++11 stack. libc++abi would be an alternative to libcxxrt, but I would prefer to use libcxxrt because: - I am totally biased towards libcxxrt because I wrote it. - libcxxrt is already shipping in PathScale's C++ stack and has been fairly well tested. - The demangler in libc++abi is bigger than the whole of libcxxrt and allocates a lot of memory in code that is called to generate helpful errors for out-of-memory conditions. - libc++abi seems to be completely missing the exception personality function. This was the hardest thing to get right in libcxxrt (debugging code that destroys the stack as it runs is not fun), so at this point it's basically uninteresting - more code, less functionality. libcxxrt and libc++ are now in contrib and building with the base system, but are not used by anything (and are only built if you set WITH_LIBCPLUSPLUS=yes when building world, not by default). If you want to test some code with the new stack, you need to build it and then specify -stdlib=libc++ to clang++ (both when compiling and linking). I'd like to see if we can persuade libstdc++ to link against libcxxrt instead of libsupc++ (In theory this should be easy, but I've never tried it. Apple ships both linked against libsupc++). This means that code can link against libraries that use libc++ and libstdc++ without things like exceptions breaking. Eventually (FreeBSD 10 timeframe), I'd like to see the libstdc++ currently in base moved into a port so that we can ship a GNU-free C++ stack. Any complaints / comments / contradictions / opinions? David P.S. libcxxrt does support the weird GNU variant of the weird ARM variant of the C++ ABI, but I only finished that support very recently and it's not nearly as well tested as the ABI used on... everything else. It also only supports DWARF 'zero-cost' unwinding, not setjmp / longjmp unwinding, so it can't be used until we finish moveing ARM to EABI. [1] http://libcxx.llvm.org/ [2] https://github.com/pathscale/libcxxrtReceived on Sat Nov 26 2011 - 19:59:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC