How can I change the filename of a shared library after building a program that depends on it?

故事扮演 提交于 2019-11-28 04:11:25

HT - this might be helpful.

HT is a file editor/viewer/analyzer for executables. The goal is to combine the low-level functionality of a debugger and the usability of IDEs. We plan to implement all (hex-)editing features and support of the most important file formats.

I couldn't find something much different from ZorbaTHut's solution, but perhaps it's possible to put a name with different length and still keep the binary valid.

gelf - this could be useful too.

GElf is a generic, ELF class-independent API for manipulat- ing ELF object files. GElf provides a single, common inter- face for handling 32-bit and 64-bit ELF format object files.

We can use patchelf:

patchelf --replace-needed liboriginal.so.1 libreplacement.so.1 my-program

We can also remove a dependency:

patchelf --remove-needed libfoo.so.1 my-program

Add a dependency:

patchelf --add-needed libfoo.so.1 my-program

Or change the path where to search for the libraries (rpath):

patchelf --set-rpath /path/to/lib:/other/path my-program

Posting a tentative, horrible, hacky solution.

The library dependencies are stored in an ELF block known as the .depends block. The format of that block is a large array of identifier/stringpointer pairs, with the stringpointer pointing to a standard C null-terminated string located somewhere in the binary.

You see where this is going, right?

Yep, as long as the new path you need is no larger than the old path, you can just reach right into the binary and do a simple string replace. Make sure not to add or remove bytes or you'll break the entire binary. If you want to be safer about it, you could actually traverse the ELF structure to ensure you had the right location - right now I'm just checking to make sure the source string shows up exactly once.

ELF does include a checksum, but apparently there's no loader that actually verifies it, so it's "safe" - albeit messy - to ignore.

The "real solution" would be a utility that allowed low-level generalized manipulations of the ELF structure. As near as I can tell, no such utility exists, for anything except a few specialized cases (RPATH, mostly.) I don't pretend to know how difficult such a utility would be to write.

I would absolutely love a better solution to this, but, so far, this appears to work.

You can use LD_LIBRARY_PATH to change the search path for shared libraries. If your program depends on a particular relative path like your example shows, you will still need to have that directory structure. In other words you can move the lib from /home/user/dev/project/this/is/terrible/library.so to /usr/local/lib/this/is/terrible/library.so but not to /usr/local/lib/library.so

If you can rebuild your program, then you can change the relative path it uses for the lib.

There's some more info on shared libs in Linux at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!