This is the mail archive of the
mailing list for the binutils project.
Re: Run with 2 different DSO versions
- From: Vladimir Simonov <sv at sw dot ru>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-help at gcc dot gnu dot org, binutils <binutils at sourceware dot org>
- Date: Fri, 30 Sep 2011 18:50:58 +0400
- Subject: Re: Run with 2 different DSO versions
- References: <4DD2993D.email@example.com> <firstname.lastname@example.org> <4DD2A470.email@example.com> <4E846D69.firstname.lastname@example.org> <email@example.com>
On 09/29/2011 09:13 PM, Ian Lance Taylor wrote:
Vladimir Simonov<firstname.lastname@example.org> writes:
Could you recommend something to solve the following problem?
1. Application is dynamically linked with COMMON_DSO_V2 and THIRD_PARTY_DSO.
2. COMMON_DSO_V2 is dynamically linked with COMMON_SUPP_DSO_V2.
3. THIRD_PARTY_DSO is dynamically linked with COMMON_DSO_V1 and
COMMON_SUPP_DSO_V1. All (three) of them are available in binary form only.
4. Source code of App, COMMON_DSO_V2 and COMMON_SUPP_DSO_V2 is available.
5. Because all COMMON_* DSOs have different sonames, all of them are loaded
at runtime. DSOs sonames:
COMMON_DSO_V2 - COMMON_DSO_V2;
COMMON_SUPP_DSO_V2 - COMMON_SUPP_DSO_V2;
COMMON_DSO_V1 - COMMON_DSO (no version in soname);
COMMON_SUPP_DSO_V1 - COMMON_SUPP_DSO (no version in soname);
6. Because DSOs COMMON_DSO_V1 and COMMON_DSO_V2(COMMON_SUPP_DSO_V1
and COMMON_SUPP_DSO_V2) in fact are just different versions of the same
library they have(export) lots of symbols with equal names. As
result App crashes with stack
App -> THIRD_PARTY_DSO -> COMMON_DSO_V1 -> COMMON_SUPP_DSO_V2 -> crash.
I'm looking for the best(simplest) way to resolve symbols names conflict.
As I know COMMON_* DSOs do not use any system-wide resources so their
different versions should coexist without problems if I eliminate conflict of names.
The most obvious way - to mangle somehow all symbols names in COMMON_DSO_V2 and
COMMON_SUPP_DSO_V2 in their headers and sources, but there are too many of them...
Hope some binutils/gcc/ld-linux magic may help with the issue.
It sounds like you can rebuild COMMON_SUPP_DSO_V2 and COMMON_DSO_V2. In
that case, rebuild them with a version script which gives a version to
all of the symbols. That will make the dynamic linker in effect think
that their symbols have different names which do not conflict with the
symbol names in COMMON_DSO_V1 and COMMON_SUPP_DSO_V1. If you are lucky,
the dynamic linker will associate THIRD_PARTY_DSO with the _V1 versions
while associating your app with the _V2 versions. I don't know for sure
that this will work--using versioning works in general, but I don't know
what will happen when you have one library with versions and one
If that doesn't work I don't know what you can do other than access
COMMON_DSO_V2 via dlopen rather than linking it in directly.
Thank you a lot!
Really before my first letter I've played with version script
but without success. Your answer encouraged me to be more persistent.
So, the solution:
1. Place symbols from COMMON_SUPP_DSO_V2 and COMMON_DSO_V2 into
"version namespace"(give some version to all exported symbols).
2. Preload COMMON_DSO_V1 and COMMON_SUPP_DSO_V1 before App start
Without the second the first doesn't work.
BTW In my experiments I've found that gold doesn't support
--default-symver and --default-imported-symver ld options.
I'm using binutils 2.21.
It is not a problem for my usecase but may be it make sense
to file a bug...
Thank you again