Re: libstdc++.so.5 vs. libstdc++.so.6 and external libraries

[Yuval Kfir]

Paul Pluzhnikov wrote:
> If you can verify that no 'same-named global symbols with
> different size or layout' exist in your code and client code, nor
> in libstdc++.so.5 and libstdc++.so.6, then I *think* you should be
> safe. Of course the fact that there are linker warnings, means that
> you probably aren't.
>
> Also, the mere fact that /usr/local/gcc-3.4.0/lib/libstdc++.so.6 and
> /usr/local/gcc-3.3.2/lib/libstdc++.so.5 (on Linux) contain 269
> potentially-conflicting symbols (globals with the same name),
> should give one a pause.

First of all, thanks for the explanation!
To clarify, I get no warnings other than a generic "libstdc++.so.5 may
conflict with libstdc++.so.6".  No warnings of symbols with different size
or stuff like that.

We suspected that exceptions and the STL globals are the two most likely
sources of conflict, but my reasoning is:
1. We don't use STL in our libraries, though our users might. Since the
application is always a user application using our libraries, libstdc++.so.6
will get loaded first and thus its STL implementation will be the one used.
2. We have a potential problem with cross-library exceptions on Linux
anyway... and intra-library exceptions will still work,  since they use
internally consistent structures.
3. The changes page for libstdc++.so.6 explicitly states that it breaks
binary compatibilty in MIPS.  It does not say that about any other
platform... I realise that's not a commitment, though.

I don't assume that if I can't think of any tests to make it crash then it
will never crash. I am trying to understand what has changed that might
constitute a risk, and whether in our case those risks do not apply (or only
apply in certain specific cases we can warn our users about).

- Yuval