Re: versioning C++ includes

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Tue, Jun 25, 2002 at 09:54:27PM +0200, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> | ... existing practice solves the version problem for programs 
> | that use only libstdc++.so.  People using g++ sometimes also use other 
> | C++ libraries.  There is no good solution in place to allow them to use 
> | two libraries of the same release version, but built with different 
> | compilers.  This is necessary if you hope to run two C++ programs you 
> | didn't build.  Without a solution, everybody building for "your"
> | machine and who uses any C++ library has to use the same compiler
> | version, because there's no place to put the libraries they need.
> | 
> | Do you see the problem?
> 
> I see the problem but, I don't think we can do anything better then
> what Benjamin is proposing.  People using other C++ runtime systems are
> out of the realm of V3.  People using other C++ libraries, but retaining
> our runtime system should view V3 as an *integral part* of the compiler.
>
> Anything other than that is out of the scope of V3.  We already have
> pains withg libtools.  I'm not convinced that we should duplicate them
> one more time. 
> 
> C++ is designed so that there is no clear separation between the
> language and the runtime system, therefore fiddling with different
> ABI+compiler isn't something that is going to work.

I see that I have failed to explain what I mean.  I will try again,
more carefully.  

Postulate two developers, Anne and Bill.  Anne writes a payroll
program, "pay".  Bill writes a video game, "play".  Both use an XML 
library, perhaps libxerces-1.3.  Anne uses gcc-3.1.1.  Bill uses 
gcc-3.2.  Anne has a libxerces built with the same compiler she uses, 
and Bill does the same.  They have no reason to talk to one another.

Along comes Carl, who wants to run pay, and (while waiting for 
it to print checks) wants to run play.  Each package depends on 
libxerces1.so.1.3.  However, the .so files they linked against
were built with different compilers that support different ABIs.  
How can Carl run both pay and play on the same machine?

One way to solve this sort of problem is to incorporate build-
environment information into the name of the library, e.g. 
libxerces-gcc3.1-1.3 and libxerces-gcc3.2-1.3.  This is a bit 
clumsy, because then the makefile has to know the compiler 
version, to enable it to link the program against -lxerces-gcc3.1 
or -lxerces-gcc3.2.  It also makes package dependencies messy to 
describe.  

Another way to solve it is to put libraries built with a
particular compiler in a directory that the compiler, and
anything built with it, knows about.  Then, the .so file
doesn't need to have a funny name, and the two can happily
live together on the same machine, ready to provide support
for running both programs pay and play.

The alternative is for Carl (or, rather, whoever set up Carl's
distribution) to insist that all the programs that run on Carl's
machine, and want to use C++ libraries like libxerces*.so, have to 
build with a particular C++ compiler version, maybe gcc-3.0.4.  
Ldso studliness lets Carl have libxerces-1.2 and libxerces-1.3 on 
his machine for different programs to use, but he can't have two 
libxerces-1.3s built with different compiler releases.  The effect 
is that the distribution vendor is obliged to declare an "official" 
(and probably ancient) C++ compiler version that is the only version 
usable for building library packages, and the only version usable for 
building programs to use them.

A solution to this problem would make it enormously easier for
users to adopt newer C++ compiler releases.  Over time, as the 
library ABI stabilizes, more and more released versions of the
compiler will be able to share the same third-party library
builds, but the problem will never go away entirely.

We can solve it by making a directory where our .so files go, and
inviting builders of C++ libraries that depend on our .so files
to put their libraries there too.  Then we just have to arrange
for our binaries to look there.  If we wanted to be thorough, we
might --rpath the "gcc-$abi_version" subdirectory of each directory
mentioned in a -L option.

C++ library package maintainers will still have to label (in the
name or in the version) which compiler version was used to build
their package, but those packages may then co-exist on the same 
machine, and satisfy dependencies for programs built from anywhere.

Nathan Myers
ncm at cantrip dot org