16

How can I force using a local library over the system library in linux?

I linked my executable explicitly to some .so files in my project/lib directory e.g. (../lib/libluajit.so).

Running my executable under gdb or using ldd shows that it still uses the system libluajit-5.1.so.2

I then set LD_LIBRARY_PATH to my project/lib directory and exported it, then ran my executable. Somehow it's still picking up the system library (confirmed by both gdb and ldd)

I'd like to know how that's even possible, and what I can do to force it to use the local libluajit.so in my project/lib directory.

Eloff
  • 20,828
  • 17
  • 83
  • 112

2 Answers2

26

When you link, specify the directory of the library and also use an rpath:

-Wl,-rpath,/absolute/path/to/your/library -L/absolute/path/to/your/library -llibrary

-L tells the linker where to find your library at link time, and -rpath tells it where to search for the library at runtime.

Note that -L and -rpath need the directory that contains your .so file, not the actual path of the library file itself.

Nikos C.
  • 50,738
  • 9
  • 71
  • 96
  • 1
    This doesn't work for me, somehow it still looks for libluajit-5.1.so.2 and nothing I seem to do (like removing the system library, and rebuilding the ld cache) seems to matter. The best I've accomplished is it can't load libluajit-5.1.so.2 at runtime. Where might it be getting that particular name from? No file by that name exists anymore in my system. – Eloff Nov 13 '12 at 19:55
  • @Eloff You're doing something wrong. Or, the program is trying to open the library using dlopen? Can we at least see the full command line of your link step? – Nikos C. Nov 13 '12 at 20:00
  • 2
    I'm pretty sure rpath only *Appends* to the rpath: When the library exists in a standard location that one will still be used. – Mark B Nov 13 '12 at 20:20
  • @MarkB Not here. I can `cp -a /usr/lib/libpng* /tmp` for example, and set the rpath to /tmp. Then ldd shows the executable loads /tmp/libpng15.so.15. – Nikos C. Nov 13 '12 at 20:23
  • I grepped libluajit.so and found the name libluajit-5.1.so.2 in there. So on a hunch I added a symbolic link by that name to libluajit.so and moved the system library by that name back to the system lib dir. Now using your technique loads the correct library. Thanks! – Eloff Nov 13 '12 at 20:26
7

I have to question why you want to use your own version of a library over a system-provided version (having multiple different versions floating around is nothing but a recipe for trouble and user confusion).

However, you should be able to export LD_PRELOAD=<path_to_your_shared_obj> to force it to load your own version.

Note that no mechanism to override library versions will persist through any sort of privilege elevation (for example sudo).

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • The short answer is that this build is only for me, the user build uses static libraries. – Eloff Nov 13 '12 at 19:17
  • 7
    There can be many reasons why you want to do this, eg to build an experimental piece of software without disrupting other users on a shared system using production software – adrianmcmenamin Nov 08 '13 at 19:36
  • *"I have to question why you want to use your own version of a library over a system-provided version ..."* - Maybe something like [make gdb load a shared library from a specific path](https://stackoverflow.com/q/33886913/608639). – jww Nov 09 '17 at 05:56
  • Your multi OS app was tested on specific library version where system has a different minor version e.g. libQt6Core.so.6 for system is 6.2.4 where mine is 6.5.1. – Waldemar Jul 21 '23 at 12:27