Hi Guido, Thanks for forwarding this, libc++ sounds rather promising.
Without us testing it there's no way to know for sure what kind of issues we'll see in the field, so I'll mention in the policy document draft that libc++ is a candidate for our default open C++ library subject to testing. We'll need to come up with an easy way of firing off builds with a different compiler and C++ library selected. In Userland this should be pretty easy to do, there's a makefile called shared-macros.mk which contains compiler definitions: http://hg.genunix.org/userland.hg/file/520697a05dde/make-rules/shared-macros.mk I'm not sure we would switch between the different c++ libraries but I imagine it won't be too hard to work out, although if its hardcoded in GCC like the linker collect2 runs then I'll be a little less happy. Cheers, Alasdair On 23 May 2011, at 21:22, Guido Berhoerster wrote: > > ----- Forwarded message from Howard Hinnant <[email protected]> ----- > > Date: Mon, 23 May 2011 16:08:23 -0400 > From: Howard Hinnant <[email protected]> > To: Guido Berhoerster <[email protected]> > Cc: [email protected] > Subject: Re: [cfe-dev] libc++ ABI stability > > On May 23, 2011, at 2:27 PM, Guido Berhoerster wrote: > >> Hello, >> >> does the LLVM project make (or plan to make) any commitment with >> regard to the ABI stability of libc++? > > The plan is to keep the ABI semi-stable. The high level parts of the library > are ABI-versioned using the C++11 feature inline namespaces. The current > version is 1. This is considered an ABI version. And the ABI for any given > version is meant to be fixed. > > Every once in a great while (e.g. maybe for the next C++ standard), we could > issue a new ABI, which would then live in a different inlined namespace (e.g. > std::_2). There would be config macro to choose the ABI. > > Some lower-level parts of the library are not ABI versioned. They live in > namespace std only. These will remain stable until the sun swells up and > swallows the earth (after that I can't vouch for it). These low level parts > include: > > * operator new/delete > * get/set new_handler > * typeinfo > * the exception classes > > The exception classes not only have a stable ABI, their ABI is identical to > that of gcc-4.2. This means you can throw exceptions across dyld boundaries > and not worry which C++ std::lib the recipient of your exception is using (as > long as that library is also ABI compatible with gcc-4.2). > > Howard > > > ----- End forwarded message ----- > > -- > Guido Berhoerster > > _______________________________________________ > oi-dev mailing list > [email protected] > http://openindiana.org/mailman/listinfo/oi-dev _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
