简体   繁体   中英

Change link to shared libraries

I have an executable A which uses dlopen to open a shared library libB.so (located in the same directory, so I do LD_LIBRARY_PATH=. to have my program find it properly). This library libB.so is supposed to find some of its symboles in libC.so which is also located in the same directory.

However, there is also a libC.so in /usr/lib64 (which has been compiled with different parameters so it doesn't have the same symboles) and for an unknown reason, libB.so tries to open this one instead of the one that is in the same directory. When I do a ldd libB.so I can see libC.so => /usr/lib64/libC.so instead of libC.so => /path/to/program/A/libC.so .

Is there a way to change this link in libB.so (without recompiling if possible), or if I should recompile libB.so, what makes the compiler chose to use libC.so in /usr/lib64 instead of the other one?

(note: replacing libC.so in /usr/lib64 is not an option, as I'm not the administrator of the platform)

Thanks

If I'm understanding the manpages correctly, LD_LIBRARY_PATH should supersede systemwide paths like /usr/lib64 , so I'm not sure why this isn't working.

Is it a setuid / setgid program? LD_LIBRARY_PATH is ignored for those.

Is the current path ( . ) changing, such that LD_LIBRARY_PATH=. no longer lets libB find libC?

Running your program through strace should let you see the directories that ldd is checking for libC; this might help you debug where and how it's searching.

I figured out what the problem was: I'm running on a supercomputer and of course some things are done in the background with environment variables before the program actually run. This was messing up with my shared libraries.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM