2

I have a software properly installed on Kubuntu.

Now, I am patching and testing some of its libraries.

How can I start the software from bash so that it loads my patched libraries instead of the official libs?

e.g.:
the official libs are locate in /usr/lib/
my patch libraries (used during test development) are in /home/user/dev/lib/

I tried: 

$ set LD_LIBRARY_PATH=/home/user/dev/lib/  
$ binary_app &

but to no avail.

I'd prefer a solution that can be set from the bash, but if it's not possible, I could also modify the cmake file of this C++ software.

The aim is to allow me to easily start the application either with the vanilla libs, or with my patched libs to see the differences.

Edit: it's a KDE .so file

The library I am testing is a KDE4 library. The official lib is in /usr/lib/kde4/ . In that directory, none of the library start with the lib prefix.

Whether I do: 

/lib/ld-linux-x86-64.so.2 --list  --library-path PATH EXEC

or 

ldd EXEC

The library is not listed at all.

On the other hand, if if move the original library away from /usr/lib/kde4/, the application starts but the corresponding functionality is missing.

Are KDE4 libraries loaded in a specific way? Maybe the variable to set is different...

Edit 2

All the answers are good and useful... unfortunately, it turned out that the problem does not appear to be related to the lib path setting. I'm dealing with a plugin architecture and the .so loading path appears to be hard-coded somewhere in the application. I need to spend more time within the source code to understand what's happening... Thanks and +1 to all.

augustin
  • 14,373
  • 13
  • 66
  • 79
  • 1
    You can check with `ldd binary_app` which libraries it uses. `LD_LIBRARY_PATH` should work but maybe a similar named library is in the ld cache which prevents `LD_LIBRARY_PATH` from beeing used. Or you can try ldpreload: http://stackoverflow.com/questions/426230 – rve Feb 04 '11 at 09:02
  • Yes, check whether it shall pick up you library in the absence of the real one? This try will shed some light on your situation. –  Feb 04 '11 at 09:06
  • I tried both suggestions. preload didn't work because I'm dealing with a KDE/QT app: error: QPixmap: Must construct a QApplication before a QPaintDevice – augustin Feb 04 '11 at 09:22

5 Answers5

7

From 'man bash':

When a simple command other than a builtin or shell function is to be executed, it is invoked in a separate execution environment that consists of the following. Unless otherwise noted, the values are inherited from the shell.

[....]

· shell variables and functions marked for export, along with variables exported for the command, passed in the environment

You need to 'export' a variable if it is to be seen by programs you execute.

However, you can also try the following:

/lib/ld-linux.so.2 --library-path PATH EXECUTABLE

See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Jan de Vos
  • 3,778
  • 1
  • 20
  • 16
  • Thanks. In my case, it's actually /lib/ld-linux-x86-64.so.2 . It still doesn't work, probably because I'm dealing with a KDE4 shared object. See edit to the question. – augustin Feb 04 '11 at 09:18
  • Even though it was rve who pointed out the source of my actual problem (hard-coded .so loading procedure/path), I accept this answer because it might me the most useful to someone reading this question with a similar problems. The other answers were all useful as well. +1 to all. – augustin Feb 04 '11 at 09:43
5

Try export LD_LIBRARY_PATH=... instead of set.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • In either case echo $LD_LIBRARY_PATH outputs the proper path. Using export does not seem to make any difference... :( – augustin Feb 04 '11 at 08:49
  • 3
    @augustin - you won't see the difference from the shell. But processes started from the shell inherit only exported variables. – atzz Feb 04 '11 at 09:26
3

I already put this in a comment but after thinking about it I think the best way to do this (using a different library just for testing/debugging) is using LD_PRELOAD, see What is the LD_PRELOAD trick?

From the man page:

LD_PRELOAD

A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set-user-ID will be loaded.

Update:

After the updated question it seems the application is using dlopen to open the library using a absolute path. I don't think you can do anything about it. See man dlopen

Update2:

Maybe there is something you can do: you might be able to LD_PRELOAD your own dlopen function which modifies the path to your own library...

Community
  • 1
  • 1
rve
  • 5,897
  • 3
  • 40
  • 64
  • it seem you are right: I need to spend more time in this app's source code to understand how the .so are loaded. See edit 2. I grepped for dlopen but got zero result. I need to investigate more and/or contact the actual application developer to see how it works. Thanks. – augustin Feb 04 '11 at 09:41
2

Isn't you app setuid or setgid by chance? In this case LD_LIBRARY_PATH will be ignored.

2

Put everything on one line:

LD_LIBRARY_PATH=foo binary_app&
KitsuneYMG
  • 12,753
  • 4
  • 37
  • 58