Library Path Order 11.2
in [Suse]
|
Prev: Php undefined variable
Next: sped up desktop effects
From: Craig Andersen on 13 Jun 2010 07:52 Michael Soibelman wrote: > Michael Soibelman wrote: > >> Craig Andersen wrote: >> >>> >>> Is there a place where the default dynamic library path is set for >>> executables ? The default LD_LIBRARY_PATH load perhaps. >>> >>> I noticed that the path /usr/lib64/tls, /usr/lib64/x86-64, /usr/lib64 >>> were checked prior to the ld.so.cache (set up by ldconfig). >>> >>> I have a /usr/local/lib entry in ld.so.cache but since it picks up the >>> /usr/lib64 version first, no joy. >>> >>> It is preferable to not mess with LD_LIBRARY_PATH. >>> >>> Just trying to understand the library load order by default, my example >>> sets up a 64 environment obviously. >> >> I've read and re-read your post and it 'seems' to be 'confused'. So, I'll >> ask you what exactly you are trying to run ?? >> >> It seems you are on a 64bit system. It also seems that you have installed >> a library file in /usr/local/lib and then ran 'ldconfig' as root to update >> your linker cache ?? Now is this a library that is needed to run >> your 'executable' file ?? Is this library not available as a regular rpm >> package so that you can install it in the normal way ? If >> the 'executable' file is one that you compiled from source did you not >> first install that required /usr/local/lib file and then compile >> your 'executable' with the path to your library file passed at >> the './configure' step ?? >> >> Please tell us what you are trying to do/run that is failing. >> >> Confused& Tired >> >> >> P.S. Perhaps a symlink is in order ? > > Or perhaps you need to add /usr/local/lib to your PATH ??? > Check to see if this is the case ?? If so just add this location to your > PATH environment variable. I have 2 options. [1] Change LD_LIBRARY_PATH so that the /usr/local/lib is before /usr/lib64 [2] Move the current libraries in /usr/lib64 to somewhere temporarily so that the /usr/local/lib libraries to be found I guess this is trivial, I just wanted to find out where the library path was set since there are some directories that are scanned prior to the ld.so.cache directories, perhaps like was stated also that when you build the application (wireshark in this case) the library path is set in the executable, I will keep looking, that is probably the answer but I can not imagine wireshark setting /usr/lib64/tls.
From: Eef Hartman on 13 Jun 2010 09:12 Craig Andersen <andersen7(a)charter.net> wrote: > Is there a place where the default dynamic library path is set for > executables ? The default LD_LIBRARY_PATH load perhaps. By default THAT one should be empty, it is just to (mostly temporarily) add some application-specific library dirs. > I noticed that the path /usr/lib64/tls, /usr/lib64/x86-64, /usr/lib64 > were checked prior to the ld.so.cache (set up by ldconfig). ld.so.cache is _created_ by ldconfig, from the dirs, contained in /etc/ld.so.conf and THAT is the place you should extra permanent library dirs. And ld.so will _always_ prefer the 64-versions of the libraries for any applications, compiled IN 64-bit, the 32-bit ones will only be used for 32-bits programs. > I have a /usr/local/lib entry in ld.so.cache but since it picks up the > /usr/lib64 version first, no joy. Every reboot (or rerun) of ldconf the cache will be cleared and newly created. It is a _cache_ file, not a config one, so the contents are apt to be thrown away when new library dirs are added (which is with the install of most packages). > sets up a 64 environment obviously. What else did you expect for 64-bit applications? PS: openSUSE _does_ set up a multi-lib environment, but of course you must install the right -32bit packages for that to work: libelf0-32bit-0.8.10-37.10 Thu 10 Dec 2009 08:39:45 AM CET libelf1-32bit-0.137-8.19 Thu 10 Dec 2009 08:39:45 AM CET libesd0-32bit-0.2.39-5.1 Thu 10 Dec 2009 08:40:32 AM CET libexpat1-32bit-2.0.1-88.26.1 Wed 17 Feb 2010 07:27:22 PM CET libflashsupport-32bit-1.2-4.26 Thu 10 Dec 2009 08:41:47 AM CET libfreebl3-32bit-3.12.6-3.1.1 Sun 30 May 2010 03:01:56 PM CEST libgail-gnome-32bit-1.20.1-2.41 Thu 10 Dec 2009 09:09:16 AM CET libgcc43-32bit-4.3.3_20081022-11.18 Thu 10 Dec 2009 08:39:45 AM CET libgcj43-32bit-4.3.3_20081022-11.18 Thu 10 Dec 2009 08:52:16 AM CET libgcrypt11-32bit-1.4.1-6.7 Thu 10 Dec 2009 08:40:31 AM CET libgio-2_0-0-32bit-2.18.2-7.8.1 Thu 10 Dec 2009 08:46:20 AM CET libglade2-32bit-2.6.3-2.22 Thu 10 Dec 2009 08:50:39 AM CET libglib-2_0-0-32bit-2.18.2-7.8.1 Thu 10 Dec 2009 08:44:19 AM CET (just a small part of the 32-bits libraries, installed on "my" SLED system, the total number of 32bit packages on THAT system is more than 200). -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ******************************************************************
From: Eef Hartman on 13 Jun 2010 09:34 Eef Hartman <E.J.M.Hartman(a)tudelft.nl> wrote: > And ld.so will _always_ prefer the 64-versions of the libraries for any > applications, compiled IN 64-bit, the 32-bit ones will only be used for > 32-bits programs. I forgot to mention: /usr/lib(64) and /lib(64) are BUILT into the ld.so loader (probably including the /tls ones), they do not have to be mentioned in the ld.so.conf file. But they _always_ are searched LAST, after all the dirs in that config. For 64-bit applications you must create and add a /usr/local/lib64 directory too, /usr/local/lib (without the 64) will only be used for 32-bits compiled apps. With the file command you can find out what arch an executable is: /opt/applics/matlab-r2009b/bin/glnx86/MATLAB: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped /opt/applics/matlab-r2009b/bin/glnxa64/MATLAB: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped (I used this program because it is auto-switching 32/64 bits so has executables for both architectures available). Normal "standard" applications are ALL of the same architecture as the install (so all of /bin and /usr/bin is normally 64-bit on a 64-version of openSUSE) the architecture switch is only for the lib directories. /usr/local/bin and other "user installed" apps may vary, of course. The loader assumes that all ../lib dirs are 32-bit only and that all 64-bit shared objects are in ../lib64 directories. At least, that is how I understand it works. -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ******************************************************************
From: Craig Andersen on 13 Jun 2010 12:26 Eef Hartman wrote: > Eef Hartman<E.J.M.Hartman(a)tudelft.nl> wrote: >> And ld.so will _always_ prefer the 64-versions of the libraries for any >> applications, compiled IN 64-bit, the 32-bit ones will only be used for >> 32-bits programs. > > I forgot to mention: /usr/lib(64) and /lib(64) are BUILT into the ld.so > loader (probably including the /tls ones), they do not have to be mentioned > in the ld.so.conf file. > But they _always_ are searched LAST, after all the dirs in that config. > > For 64-bit applications you must create and add a /usr/local/lib64 > directory too, /usr/local/lib (without the 64) will only be used for > 32-bits compiled apps. > With the file command you can find out what arch an executable is: > /opt/applics/matlab-r2009b/bin/glnx86/MATLAB: ELF 32-bit LSB executable, > Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped > /opt/applics/matlab-r2009b/bin/glnxa64/MATLAB: ELF 64-bit LSB executable, > x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), stripped > (I used this program because it is auto-switching 32/64 bits so has executables > for both architectures available). > > Normal "standard" applications are ALL of the same architecture as the install > (so all of /bin and /usr/bin is normally 64-bit on a 64-version of openSUSE) > the architecture switch is only for the lib directories. > /usr/local/bin and other "user installed" apps may vary, of course. > The loader assumes that all ../lib dirs are 32-bit only and that all 64-bit > shared objects are in ../lib64 directories. > > At least, that is how I understand it works. Good info, but my experience is the libraries you mentioned are not searched last but first, hence my issue. I forgot what logic executes a program (the ld.so part). Originally I was changing the order of libraries in /etc/ld.so.conf and when that did not work doing a strace showed that those other directories were scanned first. Anyway, thanks.
From: Eef Hartman on 14 Jun 2010 05:25
Craig Andersen <andersen7(a)charter.net> wrote: > Good info, but my experience is the libraries you mentioned are not > searched last but first, hence my issue. I forgot what logic executes a > program (the ld.so part). /bin/ld-linux.so.2 (or something like it - this is 11.1 I'm running) is the "shared object" loader. With the "ldd" command you will see it as one of the shared libraries the executable file is using: $ ldd /bin/ls linux-gate.so.1 => (0xffffe000) librt.so.1 => /lib/librt.so.1 (0xb77ff000) libselinux.so.1 => /lib/libselinux.so.1 (0xb77e2000) libacl.so.1 => /lib/libacl.so.1 (0xb77d9000) libc.so.6 => /lib/libc.so.6 (0xb767d000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7662000) /lib/ld-linux.so.2 (0xb782e000) <========== libdl.so.2 => /lib/libdl.so.2 (0xb765d000) libattr.so.1 => /lib/libattr.so.1 (0xb7657000) You see it is a HARD reference, with path, not like the others which are mapped BY ld-linux to a path. I don't know exactly what the linux-gate.so.1 one is for, but it also is not a mapped shared object. -- ****************************************************************** ** Eef Hartman, Delft University of Technology, dept. SSC/ICT ** ** e-mail: E.J.M.Hartman(a)tudelft.nl - phone: +31-15-27 82525 ** ****************************************************************** |