Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"redirect" symbol search from .so to .a

7 views
Skip to first unread message

nguillot

unread,
May 4, 2011, 5:16:07 AM5/4/11
to
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.

0 new messages