This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Multiple libstdc++ versions
- From: coypu at sdf dot org
- To: libstdc++ at gcc dot gnu dot org
- Cc: coypu at sdf dot org
- Date: Sat, 1 Jul 2017 16:31:15 +0000
- Subject: Multiple libstdc++ versions
- Authentication-results: sourceware.org; auth=none
Hi libstdc++-ml!
I'm working on an OS-agnostic source package manager (pkgsrc). we've
been letting people "bring their own compilers to work".
If a compiler was too old to be usable, we would e.g. mark a minimum
required GCC version, and anyone using an older one would be
automatically building a GCC package we provide, installed to another
prefix (for example /usr/pkg/gcc7/) and hopefully everything pans out
(no promises).
The C++ world likes to race on in standards, so now it's common to require
C++11 for fairly basic packages (icu!), while some pkgsrc users like to
use RedHat 6 or an older NetBSD version with GCC 4.5, so we have to rely
on this for a lot of things.
We've had a discussion about the ramifications of doing it, as it pushes
ABI compatibility to the limits.
I assume that there's a good amount of backwards compatibility, but with
highly dependent packages, we can end up with a scenario like so:
[library A g++4.5] [library B g++4.8]
\ /
[ C package ]
If so, when I link the C package with -lA -lB, I assume the libstdc++4.5
first, causing us to rely on non-existent forward compatibility in
unpredictable ways(?)
What do you think about this scenario? are we pushing it too far?
Is it expected to work even in the case where the newer libstdc++ is
used?
(The current suggestion is that we will warmly recommend not bringing
your own compiler to work if it's older than GCC 4.8, and first build a
newer compiler and use that one for building packages)
Thanks.