This is the mail archive of the binutils@sourceware.org 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]

Run with 2 different DSO versions


Hi Ian,

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.

Thank you in advance
Vladimir Simonov


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