I'm aware of the general basics of using ldconfig
and LD_LIBRARY_PATH
, but I'm hoping for a little guru help with my situation.
I have a portable software package that resides in its own directory and has its own versions of many libraries.
There are MANY binaries and scripts that run from this directory.
Some of the binaries (apache, php, postgres) may also have separate versions installed on the system.
Since there might be two versions of php, it doesn't suffice to create /etc/ld.so.conf.d/myapp.conf
if the system can't determine which version of "myapp" to use the ldconfig file for.
I'm looking for best practices on configuring such a system. The person who initially set up the software pack exported LD_LIBRARY_PATH
so that ALL applications on the system used it.
I'm trying to isolate just the applications in the package directory.
Some parameters to work with:
/mypack
- contains everything for the software package
/mypack/local/lib
- contains required libraries that may not be compatible with the system
library example:
/mypack/local/lib/libz.so.1 => /mypack/local/lib/libz.so.1.2.3
/lib/libz.so.1 => /lib/libz.so.1.2.3
even though the versions are the same, the one in /mypack may not be compatible with the distro and will break the system if it's used
binary example: php exists in both /mypack and in the default directory php from /mypack should use libs from /mypack/local/lib and the distro version should use /lib
Some questions about linux library paths: - Is it possible to specify /etc/ld.so.conf.d/php.conf such that it only affects the version of php in /mypack? - Can the library path be specified based on the location of an executable? That is, at run time, if the path of an executable is under /mypack, can it automatically use libraries from there? - How about on a per user basis? Some/most of the system runs on different user accounts. If I were able to set a different library path per user, that would solve it.
In case anyone else finds this useful, I ended up doing this before building:
export LD_RUN_PATH='$ORIGIN/../lib'
This includes a library path in the binary itself, relative to the location of the binary. If you plan to use this in a bash script or in your build files, make sure to look up your particular usage with $ORIGIN since there are cases when you need to do something like \$$ORIGIN, \$$ORIGIN or $$ORIGIN so that different utilities involved in the build get the dollar sign escaped properly. Finding this useful bit saved me having to update about 50 individual scripts that run as a batch to build our software pack.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With