Run with 2 different DSO versions

[Vladimir Simonov]

On 09/29/2011 09:13 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  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_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
> 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.
>
> Ian
>

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
(via LD_PRELOAD).

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