libstdc++-so7 info?

[Nicholas Miell]

On Sat, 2006-03-04 at 21:50 -0300, Pedro Lamarão wrote:
> Nicholas Miell wrote:
> 
> [SNIP]
> 
> > Nice to see that somebody is finally trying to solve the problem,
> > instead of just letting the users suffer. Maybe C++ will actually be a
> > viable language for library development one day soon.
> 
> C++ is excellent for library development.

You have failed to consider what happens when multiple objects link to
different ABI-incompatible versions of libstdc++.

In such a situation, ELF symbol resolution rules cause all the libstdc++
symbols to resolve to the first instance of the library loaded
(typically the version of libstdc++ used by the main application).

If vtable layout has changed, object size or layout has changed, or some
implementation detail assumed by inlined libstdc++ functions has
changed, things blow up messily.

This will happen even if the main application doesn't actually use the
STL, because it has to link to libstdc++ anyway to get the runtime
support necessary for C++ to function. (This runtime support is actually
part of libsupc++ -- which has had a stable ABI -- but you can't link to
libsupc++ separately in the dynamic case.)

ELF symbol versioning is supposed to help with this, but apparently it
doesn't (for reasons that were never really made clear). It certainly
won't help in the case where STL objects are involved in the public
library API.

As such, the only reliable way to use C++ on Linux is to never actually
use any of the STL. This isn't something you can guarantee and decreases
the benefits of using C++ in the first place.

(And if any of this happens to be wrong, please correct me!)

-- 
Nicholas Miell <nmiell at comcast.net>