CODEWITHSUNDEEP
linuxhexshared-librarieselfdlopen
Jordie
Jordie

Reputation: 11

Hexeditted shared library 'Version x.so not found' error

My library A is dependant on external library B. When I use ld on A.so, I see B is linked as B.so.10, yet on my computer the links are:

B.so -> B.so.10

B.so.10 -> B.so.10.5

Im trying to make A link to JUST B.so and use symbolic links for what version to load. I hexeditted A.so and replaced all findings of B.so.10 with B.so, and ld links it just fine, but when I try to dlopen A.so, it says: 'Error loading A.so: Version B.so not found' I've read about symbol versioning and such, but honestly have no clue where to look for what would be causing the issue?

Ive checked readelf and compared a non editted version to mine and I see nothing in the diffs besides the SO name. Elfedit also did not work snd just turned the binary into garbage data.

Upvotes: 0

Views: 200

Answers (1)

Employed Russian
Employed Russian

Reputation: 213586

If you run readelf -V B.so, you will likely discover that it doesn't define version B.so, but does define version B.so.10.

By replacing all B.so.10 strings with B.so you state to the runtime loader that A.so depends on version B.so instead of B.so.10 that it used to depend on.

Since not such version exists at runtime, loader correctly complains.

Ive checked readelf and compared a non editted version to mine and I see nothing in the diffs besides the SO name.

Check again. In particular, do this:

diff <(readelf -V A.so.orig) <(readelf -V A.so)

You should see some differences there.

Im trying to make A link to JUST B.so and use symbolic links for what version to load.

You appear to have an XY problem. What are you really trying to achieve?

Update:

The initial problem is im trying to make my software CUDA version agnostic. ... I can't take this binary and plop it on another system with a different cufft version as cufft links to a specific version even though the ABI hasn't changed in forever.

Ah, you do in fact have an XY problem.

You can not in fact deduce that the ABI has not changed, unless you verify that every structure potentially used in that ABI has not changed (this is different from verifying that the API has not changed, and you likely did that).

If you succeed in patching out the version, the end result will likely be a mystery crash on a system with different version of CUFFT.

If you are lucky, the crash will happen quickly and reproducibly. If you are unlucky, it will happen rarely and will look completely mysterious and unrelated, will happen only on some systems, only on some customer machines, only after you make totally unrelated changes to your library, etc. etc.

TL;DR: You are setting yourself up for significant pain. Just don't do it.

Upvotes: 1

Related Questions