Proper use of LD_LIBRARY_PATH or ldconfig for software package

I know the general basics of using ldconfig and LD_LIBRARY_PATH , but I hope for the help of a little guru in my situation.

I have a portable software package that is in its own directory and has its own versions of many libraries.

There are many executables 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 may be two versions of php, to create /etc/ld.so.conf.d/myapp.conf not enough to create /etc/ld.so.conf.d/myapp.conf if the system cannot determine which version " myapp "is used for the ldconfig file for.

I am looking for recommendations for setting up such a system. The user who originally set up the software package exported LD_LIBRARY_PATH to use ALL applications on the system.

I am trying to isolate only applications in a package directory.

Some options for working with:

/mypack - contains everything for the software package

/mypack/local/lib - contains the necessary libraries that may be incompatible 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 

although the versions are the same, one in / mypack may not be compatible with the distribution and will crash the system if it uses

binary example: php exists in both / mypack and in the default directory php from / mypack should use libs from / mypack / local / lib, and the distribution version should use / lib

Some questions about Linux library paths: - Can I specify /etc/ld.so.conf.d/php.conf so that it affects only the php version in / mypack? - Is it possible to specify the path to the library depending on the location of the executable file? That is, at runtime, if the path of the executable is under / mypack, can it automatically use the libraries from there? - What about each user? Some / most of the system runs on different user accounts. If I could set a different library path for each user, that would solve it.

+6
source share
2 answers

If anyone else finds this useful, I finished this before building:

 export LD_RUN_PATH='$ORIGIN/../lib' 

This includes the library path in binary itself relative to the location of the binary. If you plan to use this in a bash script or in your build files, be sure to review your specific use with $ ORIGIN, as there are times when you need to do something like \ $$ ORIGIN, \ $$ ORIGIN or $$ ORIGIN, so that the various utilities involved in the assembly get a dollar sign. The search for this useful bit saved me from the need to update about 50 individual scripts that run as a package to create our software package.

+5
source

The problem is that LD_LIBRARY_PATH is preceded by the information provided by ldconfig. If all you want to do is set up backup libraries to install on systems that don't already have them, extract the current set of libraries from ldconfig and add them to LD_LIBRARY_PATH

 mytmp=/tmp/${USER}_junk$$ ( for i in `/sbin/ldconfig -p | grep '=>' | awk '{ print $NF }'` ; do dirname $i ; done ) | sort -r | uniq > ${mytmp} myld="" for j in `cat ${mytmp}` ; do myld=${j}:${myld} ; done rm -f ${mytmp} LD_LIBRARY_PATH=${myld}${LD_LIBRARY_PATH}:${SEP}/lib:${SEP}/lib/syslibs export LD_LIBRARY_PATH 
0
source

Source: https://habr.com/ru/post/950486/


All Articles