libstdc++-so7 info?

[Jakub Jelinek]

On Wed, Feb 22, 2006 at 11:40:20AM -0800, Nicholas Miell wrote:
> On Wed, 2006-02-22 at 07:09 -0500, Jakub Jelinek wrote:
> > On Wed, Feb 22, 2006 at 07:06:45AM -0500, Neal Becker wrote:
> > > I noticed the libstdc++-so7 preview, but I haven't been able to find any
> > > information that summarizes what is new, compared with the current
> > > libstdc++.  Any pointers?
> > 
> > It is only included for scim purposes, please don't use it for anything
> > else.  It contains various ABI breaking experimental STL changes that
> > are not applicable to libstdc++.so.6.
> > 
> 
> Oh great, they're breaking the ABI again!? When will those idiots
> learn...
> 
> How about Fedora stops including all new versions of libstdc++ until the
> maintainers manage to wrap their tiny little minds around the concept of
> a "stable ABI"?

Please don't insult people who know about C++ ABI stuff far more than
you apparently do.  There are several C++ ABI bugs both on the compiler
side (things you currently get with -fabi-version=0, PR22488 etc.)
and several things in the STL land are simply not doable without
ABI break, backwards compatibility in C++ world is a few orders of magnitude
harder in C++ than in C. G++ 3.4/4.0/4.1 have C++ ABI compatibility
and nobody said yet to my knowledge if 4.2 will or won't be compatible,
libstdc++so7 is simply a playground for things that aren't doable
without ABI break (similarly to -fabi-version=0).  If/when it is decided
to do an ABI break, all the stuff in there can be used.

>From my own experience when I was doing the long double switch also in
libstdc++, aiming for libstdc++.so.6 compatibility with both DFmode
and TFmode long double, maintaining C++ ABI compatibility is a nightmare,
you basically can't use symbol versioning and due to inheritance, inlining
and ODR things are really hard to do.

We included this in Fedora, because SCIM IM modules are written in C++
and as they need to be loaded into arbitrary Gtk (and KDE) applications,
there is a big problem if the application uses some older libstdc++.so.
This can be solved only with dlmopen (but then, SCIM IM modules use
like 40 or 50 shared library dependencies, so dlmopen isn't really a
good idea), or by namespace versioning, which is one of the things
libstdc++so7 has.

	Jakub