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