http://llvm.org/pre-releases/3.3/rc2/ includes release tarballs for
libc++, but none for libc++abi. Are there any plans for adding
libc++abi release tarballs alongside the others in the future?
Background: I'm working on getting a clang/libc++/libc++abi toolchain
working on OpenBSD, and having official libc++abi tarballs would just
make the packaging process a bit nicer.
Why don't use use libcxxrt, like FreeBSD?
No reason in particular. I'd gained an impression somehow that
libcxxrt was specific to amd64/i386, and libcxxrt's "supported
platforms" declaration in its README seemed to reinforce that view for
me. Also, when I tried searching for "libcxxabi vs libcxxrt", I
couldn't find any good arguments for one over the other, so I just
That said, does libcxxrt have releases?
libcxxrt is probably a lot smaller if that matters to you. It's stable and should be released alongside the compiler.
David - did you add ARM support? Should the readme b
git master should always be in a production ready state. Typically this isn't something which would be released standalone and should be bundled with the compiler.
binary size is much smaller than libcxxabi last time I checked.
David - Did you add ARM support and should the README be updated?
MIPS64/SPARC support may happen at some point in the future (no promises)
It is indeed smaller (100kB text and 5kB data libcxxrt.so, vs 450kB
text and 42kB data for libc++abi.so), though that's not much of a
concern to me to be honest.
The bigger win IMO is that I can build libcxxrt with GCC 4.2, which
means I can just import it into base to replace libsupc++. (By
comparison, libc++abi doesn't like libstdc++'s headers, GCC 4.2.1
can't handle libc++'s headers, and we don't have Clang in base, so I
was needing to build libc++abi out of our ports tree, which means
libstdc++ in base can't link against it.)
What's needed to support other processor architectures in libcxxrt? I
didn't notice any processor-specific code (other than ARM) in any of
libsupc++, libc++abi, or libcxxrt.
Also, is cfe-dev still the appropriate mailing list to discuss
libcxxrt, or should we move this discussion elsewhere?
If the architecture supports the same ABI I'm guessing it's just a matter of testing and bug fixes - I don't know of any target specific code in libcxxrt, but the corresponding libunwind will probably have some. I don't mind discussing this here if others don't mind, but bug reports should go to our github though.