[cfe-dev] Proposal: Managing ABI changes in libc++

[David Chisnall]

On 20 Dec 2014, at 03:19, Marshall Clow <mclow.lists at gmail.com> wrote:

> It’s not the users that will be picking and choosing.
> I’m thinking of the people that ship libc++ as part of their systems.
> [ Mac OS, FreeBSD, Android, iOS, etc ]
> 
> Each of them have different requirements for ABI stability.

To make this concrete, in FreeBSD we ship libc++ as part of the base system.  This means that we *must* be able to preserve the ABI for five years.  We are able to ship a new, ABI-breaking, version with each new major release (i.e. every 2 years), but we must then support that ABI for the next five.  We are likely to end support (which really means security updates) for the 10.x series (which was the first to contain libc++) in early 2019. 

Our lives would probably be made easier if we could build a single libc++, with different namespaces for the different ABI versions.  We'd then be able to bump the .so version when we switched the headers to a new ABI, but old binaries would still work (you just wouldn't be able to mix them with new binaries in the same process if they passed standard library types across library boundaries - this would be a linker error though, and easy to diagnose).  Building multiple .so versions would not be significant overhead though and we can just put the older one in a compat package.

For static linking, being able to build with -DLATEST_AND_GREATEST (or whatever) and not have any of the legacy compat code compiled in would probably be nice.

David