Implications of tighter integration of libg++

[Joe Buck]

[ changes in libstdc++ interface ]

> > Even so, perhaps a backward compatibility layer could be written.  But it
> > might be easier just to ship two libstdc++ versions with different major
> > version numbers than to try to figure out how to make one library do.

> Why couldn't you just have the compatibility layer in a separate library?

Well, that's what two libraries give you.  Ah, but you want a small
compatibility layer rather than an entirely separate library.  This is
possible, but in the absence of a volunteer to do the job it isn't going
to happen.

> That way those symbols would only be used if it were explicitly added to
> the link command.

Doesn't work.  Either you have source or you have an executable.  If the
executable uses the old interface and is dynamically linked, there is no
link command, only ldd.  The only control you have is LD_LIBRARY_PATH or
equivalent. (OK, you might also have an old library, and there you could
use a link command).

> For those sites that didn't care about using the 
> previously reserved symbols, it could be automatically linked or even be
> included as a separate object in the standard library.

We can't put the old interfaces in the standard library.  If we get to the
point that g++ is essentially standard-conforming, it would be a disaster
to then completely break standards conformance for the sake of g++-2.7.x
or even g++-2.8.x compatibility.  If a means were provided, it would have
to be done in a way that extra action is required to get the compatibility
stuff -- explicitly point to an old library or a compatibility library.