This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Run with 2 different DSO versions

On 09/29/2011 09:13 PM, Ian Lance Taylor wrote:
Vladimir Simonov<> writes:

Could you recommend something to solve the following problem?

OS Linux.
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_V1 - COMMON_DSO (no version in soname);
COMMON_SUPP_DSO_V1 - COMMON_SUPP_DSO (no version in soname);
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

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 without.

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
Vladimir Simonov

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]