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 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
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
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.