I want to distribute an executable in my app. Problem:
The executable depends on the exact (to 1st decimal) version of the shared library.
If I make the app dependent on swi-prolog, it has to be the exact version which may not be the one in the user’s distro, or if installing it themselves they may not want that version
If I include the shared library in my app, it will clash if the user does want to install the same version (package management problem)
So…can I get the swipl library linked statically in my standalone?
Otherwise my only option is to bundle libswipl.so in my app’s tree and attack the standalone executable with patchelf to make it look for it in the new place, which I have done by hand so far bit is tricky to script in a makefile.
I was trying to do something similar previously & resorted to making the binary + libswipl.so (+ some other shared libraries) & started the binary with a script that set LD_LIBRARY_PATH to point to where those .so’s live. I would very like to have a better solution as well…
You can compile the system using a static library. For the current CMake versions this implies adding -DSWIPL_SHARED_LIB=OFF to the CMake configure run. I don’t remember about the old stuff. It is probably wise to upgrade anyway, both for stability, performance and notably support for deployment.
I think Linux also allows using RPATH to use a path relative to the executable. See chrpath and ld.so.
Thanks, chrpath looks like a slightly more mainstream way of doing what I have been doing with patchelf (oops typo in original post). Since I am building in a managed chroot jail (as recommended for Debian packages) this is easier than trying to rebuild swi-prolog statically linked.
Have to keep using patchelf because the arm versions of libswipl.so do not have an rpath as installed, and chrpath cannot create one if it does not already exist. Unfortunately that means I cannot build for distros older than xenial…