Dynamic library path hardcoded into executable

Hey all,
Like the title says, I just noticed that when I build an executable with QT Creator and ofxMSATensorFlow, the executable contains an absolute path to the libtensorflow_cc.so file, so if i were to copy the binary to another computer and run it, I get an error:

error while loading shared libraries: /path/to/my/original/openframeworks/addons/ofxMSATensorFlow/libs/tensorflow/lib/linux64/libtensorflow_cc.so: cannot open shared object file: No such file or directory.

This happens even if I install the dynamic library on the new PC (script which does this is here).
I’ve also tried export LD_LIBRARY_PATH to add the path for that session.

ldconfig -p | grep libtensorflow* 


libtensorflow_cc.so (libc,x86-64) => /home/me/lib/libtensorflow_cc.so

So it’s definitely in the system :slight_smile: But the binary somehow has the path hardcoded. I couldn’t find out how to fix this. Any ideas?

EDIT: oh and ldd ./mybin does show that it’s looking for lintensorflow_cc.so in that absolute path.

in linux you can use rpath to specify where to look for dynamic libraries. with qtcreator you can use cpp.rpaths to specify this search paths, the syntax is the same as other config settings, a js array of strings

oh super thx, yea I came across rpath but couldn’t figure out how to us. still learning linux :slight_smile:

So I put this in the qbs? I still can’t get it to work :s: I tried all of the below, and still when I do ldd mybin it shows the full path to my addon/lib dir. (I was hoping to be able to just package the lib in with the executable dir, and on the other computer have a script that sets LD_LIBRARY_PATH to ‘.’ and then run the exe, don’t know if that would work?)

    of.linkerFlags: []      // flags passed to the linker
    of.defines: []          // defines are passed as -D to the compiler
    of.frameworks: []       // osx only, additional frameworks to link with the project
    cpp.rpaths: ["./libtensorflow_cc.so", "./libtensorflow_cc", "./tensorflow_cc", "./", "libtensorflow_cc.so", "libtensorflow_cc", "tensorflow_cc", "."]

mmh the problem might be that the automatic config for the addon includes the absolute path to the library and that makes the linker hardcode the absolute path to that library in the binary

we should probably change that to a combination of -l and -L flags, can you try to add that manually to your addon_config.mk in ADDON_LDFLAGS

something like:

ADDON_LDFLAGS = -ltensorflow_cc -L/path/to/my/original/openframeworks/addons/ofxMSATensorFlow/libs/tensorflow/lib/linux64

to see if that works? if it does it should be relatively easy to change the way we include dynamic libraries to a combination of -l -L, we don’t do that now to be sure that the addon library is always linked and not some other version installed on the system

you might need to add the library in the ADDON_LIBS_EXCLUDES

ok I tried both of these individually (the lib is in both)

   ADDON_LDFLAGS = -ltensorflow_cc -L/mnt/data/dev/openframeworks/of_v0.9.8_linux64_release/addons/ofxMSATensorFlow/libs/tensorflow/lib/linux64
   ADDON_LDFLAGS = -ltensorflow_cc -L/home/memo/lib

in both cases it links, but ldd still always returns the full openframeworks path, even when i give it the one in lib.