Just a quick note. I fully support moving to an open C++ library, but be advised that we will still need the closed Sun binaries in order to support legacy apps. Of course I think nobody should use C++ but that is a different rant and probably highly controversial. :)
-- Garrett D'Amore On May 24, 2011, at 12:07 PM, "Alasdair Lumsden" <[email protected]> wrote: > 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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
