"redirect" symbol search from .so to .a

[nguillot]

Hello.

I specify my question:
I have an executable, let it be MyExe.
It used (dynamic link) a vendor lib, let say vendor.so, and I can't
compile it myself.
The vendor.so is dynamically link to another vendor lib, let say:
boost_thread_1.35.so (name chosen totally by chance ;-)), this
boost_thread_1.35.so is provided by the vendor.
MyExe is also dynamically linked to one of my libs: let say myLib.so,
this latter being dyn. linked to boost_thread_1.44.so.

"Graphically":

MyExe
/\ /\
| |
vendor.so myLib.so
/\ /\
| |
boost_thread1.35 boost_thread_1.44

The issue is:
boost_thread1.35 and 1.44 defines the same symbols are not compatible.
MyExe really needs boost in version 44 (not 35).

I played to check the issue:
1) when MyExe only uses functions of vendor.so (and so
boost_thread1.35)
1.1) when boost_thread1.35 is loaded before 1.44 by the system (I
check with strace): no problem
1.2) when boost_thread1.44 is loaded before 1.35: seg fault.
2) when MyExe only uses functions of myLib.so (and so
boost_thread1.44)
1.1) when boost_thread1.44 is loaded before 1.35 by the system: no
problem
1.2) when boost_thread1.35 is loaded before 1.44: seg fault.
3) when MyExe uses both functions of myLib.so and vendor.so: seg
fault whatever the load order of the boost thread libs.

The solution I think about:
I can compile the boost_thread 1.35 as a static lib.
I wonder if I can do something with that: I'd like to be able to say
to vendor.so: "don't search your symbol in boost_thread1.35.so,
but" ....where? And : "don't be dynamically linked to
boost_thread1.35.so".
And how to say that?

Any suggestion?

Thanks in advance for answers.

 

[Öö Tiib]

Hello.

I specify my question:
I have an executable, let it be MyExe.
It used (dynamic link) a vendor lib, let say vendor.so, and I can't
compile it myself.
The vendor.so is dynamically link to another vendor lib, let say:
boost_thread_1.35.so (name chosen totally by chance ;-)), this
boost_thread_1.35.so is provided by the vendor.
MyExe is also dynamically linked to one of my libs: let say myLib.so,
this latter being dyn. linked to boost_thread_1.44.so.

"Graphically":

                  MyExe
                  /\       /\
                  |        |
        vendor.so   myLib.so
                 /\           /\
                 |             |
boost_thread1.35  boost_thread_1.44

The issue is:
boost_thread1.35 and 1.44 defines the same symbols are not compatible.
MyExe really needs boost in version 44 (not 35).

I played to check the issue:
1) when MyExe only uses functions of vendor.so (and so
boost_thread1.35)
1.1) when boost_thread1.35 is loaded before 1.44 by the system (I
check with strace): no problem
1.2) when boost_thread1.44 is loaded before 1.35: seg fault.
2) when MyExe only uses functions of myLib.so (and so
boost_thread1.44)
1.1) when boost_thread1.44 is loaded before 1.35 by the system: no
problem
1.2) when boost_thread1.35 is loaded before 1.44: seg fault.
3) when MyExe uses both functions of myLib.so  and vendor.so: seg
fault whatever the load order of the boost thread libs.

Sounds like lot of fun. What exactly does crash?

The solution I think about:
I can compile the boost_thread 1.35 as a static lib.
I wonder if I can do something with that: I'd like to be able to say
to vendor.so: "don't search your symbol in boost_thread1.35.so,
but" ....where? And : "don't be dynamically linked to
boost_thread1.35.so".
And how to say that?

That can't be done i am afraid.

Any suggestion?

With such closed-source .so module in same process it will anyway
continue to be problematic and difficult to debug ... even if you find
some trick to avoid crashes at hand.

Consider moving the module(s) that use services of such "vendor.so"
into separate executable. Other modules can communicate with it over
whatever inter-process channels you are most familiar with.

 

[nguillot]

Sounds like lot of fun. What exactly does crash
The call of some function on boost_thread. In my sample code, I just
start a thread (thanks to boost::thread) on a function doing nothing

Consider moving the module(s) that use services of such "vendor.so"
into separate executable. Other modules can communicate with it over
whatever inter-process channels you are most familiar with.

Yes, that's what I did, but performances suffer!

 

[Samkit Jain]

(e-mail address removed):














GNU dynamic linker is quite sophisticated and actually has some concept
of symbol visibility restriction (see e.g. ldopen() and RTLD_PRIVATE) so
I suspect what you want to do should be possible somehow. However, this
is not a C++ question, rather a dynamic linker question so I suspect you
could get better help in some GNU/Linux forum.

hth
Paavo

When you are switching the places of libraries i.e. using 1.44 before
1.35 then are you compiling and loading in same sequence? Or are you
compiling like 1.35->1.44 and running with LD_LIBRARY_PATH as 1.44-

 

[nguillot]

When you are switching the places of libraries i.e. using 1.44 before
1.35 then are you compiling and loading in same sequence? Or are you
compiling like 1.35->1.44 and running with LD_LIBRARY_PATH as 1.44-

I'm not sure I understand.
Here some details of the cases I explained:

1.1) MyExe only uses functions of vendor.so (and so boost_thread1.35)
and boost_thread1.35 is loaded before 1.44 => no problemo
%> export LD_PRELOAD=/opt/boost_1_35_0/lib/libboost_thread_1_35.so
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("/opt/boost_1_35_0/lib/libboost_thread_1_35.so", O_RDONLY) = 3
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3

1.2) MyExe only uses functions of vendor.so (and so boost_thread1.35)
and boost_thread1.44 is loaded before 1.35 => seg fault
%> export
LD_PRELOAD=
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("/opt/boost_1_35_0/lib/libboost_thread-gcc44-mt-1_35.so.1.35.0",
O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3
zsh: segmentation fault

2.1) MyExe only uses functions of myLib.so (and so boost_thread1.44)
and boost_thread1.44 is loaded before 1.35 => no problemo
%> export LD_PRELOAD=
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("/opt/boost_1_35_0/lib/libboost_thread-gcc44-mt-1_35.so.1.35.0",
O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3

2.2) MyExe only uses functions of myLib.so (and so boost_thread1.44)
and boost_thread1.35 is loaded before 1.44 => seg fault
%> export LD_PRELOAD=/opt/boost_1_35_0/lib/libboost_thread_1_35.so
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("/opt/boost_1_35_0/lib/libboost_thread_1_35.so", O_RDONLY) = 3
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3
zsh: segmentation fault

3) MyExe uses both functions of myLib.so and vendor.so: seg fault
whatever the load order of the boost thread libs.
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("/opt/boost_1_35_0/lib/libboost_thread-gcc44-mt-1_35.so.1.35.0",
O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3
zsh: segmentation fault
%> export LD_PRELOAD=/opt/boost_1_35_0/lib/
libboost_thread_1_35.so
%> strace ./MyExe 2>&1 | grep 'boost_thread\|Vendor\|MyLib' | grep -v
file
open("/opt/boost_1_35_0/lib/libboost_thread_1_35.so", O_RDONLY) = 3
open("../../Vendor/Release/libVendor.so", O_RDONLY) = 3
open("/opt/boost_1_44_0/lib/libboost_thread.so.1.44.0", O_RDONLY) = 3
open("../../MyLib/Release/libMyLib.so", O_RDONLY) = 3
zsh: segmentation fault