[cfe-dev] How to package library TSes

[David Chisnall]

Hi Marshall,

For some background: We ship libc++ in both the base system and in ports.  Some things use the version in ports, but we expect it to be a drop-in replacement (i.e. if something links libc++ and works with the one in base, then it must also work with the one in ports).  Mostly the one in ports is used by things that require C++14 on systems that ship a libc++ that’s C++11-only.

If we’re going to ship them in the FreeBSD base system at all, then we need to be able to guarantee ABI (and API) compatibility over the lifetime of a FreeBSD release (5 years).  This means that we’d want to make sure, at the very least, they they’re in versioned namespaces and that people can opt in to newer ones if they want, but still have the older ones available.

As to which library it goes in, having one library is attractive even if it means that it’s going to grow a load of compat code over time.  For FreeBSD 12, we’d happily turn off the compat code with FreeBSD 11 (and provide a compat version with it enabled) and some people building embedded systems may wish to turn it off in their builds anyway.  Having them as separate libraries doesn’t really address this problem.  Having them as static libraries is likely to cause issues when two or more shared libraries link against them.

David

> On 21 Jul 2015, at 19:38, Marshall Clow <mclow.lists at gmail.com> wrote:
> 
> There's a lot of changes coming to the standard library. The standards committee is looking at (and in several cases, approved) proposals for networking, ranges, concurrency, parallelism, transactional memory, file-system, and concepts. Each of these will require changes to the standard library.
> 
> Some (most) of them are "Technical Specifications", which means that they are not officially part of the standard. The goal for then TS-es is to give implementors and users experience with the features, so that the standards committee can get feedback about when (and if) they should be adopted into the standard.
> 
> The other part of this is that the TS-es *change*. People give feedback, and the committee updates the proposals, and the code changes. There's a reason that most of them live in the namespace "std::experimental".
> 
> Some of these proposals can be implemented as templates that live in a header file, and require no new functionality from the dynamic library libc++.dylib. Most of them, however, have a separately compiled part, and that is the purpose of this email.
> 
> How should these parts be delivered? 
> 
> The choices, I see, are:
> * As part of the libc++ dynamic library.
> * As a set of statically linkable object libraries.
> * As a set of dynamic libraries.
> * Something else
> 
> The first option, it seems to me, is a non-starter. There are some systems (FreeSBD, Mac OS X) that ship libc++ as the system runtime library, and replacing that library (on the fly) is a easy way to render your system inoperative. 
> 
> On the other hand, having the vendors ship updated libraries a few times/year (or less) is a great way to slow down the entire process.
> 
> So, I'm asking - what do people want?  (and why)
> 
> -- Marshall
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev