I would like to override the "standard" libGL.so files by a "private"
library installed in a special directory. Problem: It seems that
the libraries in in /lib and /usr/lib have a higher priority than any
other directory. This is a severe restriction. Looking at ld.so(8)
I had the impression that /lib and /usr/lib are supposed to provide a
_default_ set of libraries to be overridden by ld.so.conf and
$LD_LIBRARY_PATH as needed;
:
:
The necessary shared libraries needed by the program are searched for in the following order
o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH for a.out programs). Except if
the executable is a setuid/setgid binary, in which case it is ignored.
o From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously
found in the augmented library path.
o In the default path /lib, and then /usr/lib.
:
:
Here is my setup:
% cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
% cat /etc/ld.so.conf.d/*.conf
/usr/lib/nvidia-current
/usr/lib32/nvidia-current
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
AFAICS this is Debian's default, except for the nvidia libs. Please note
that there is neither /usr/lib nor /lib included in this list.
ldd and strace show that the library is taken from the wrong directory.
Sample session:
% cat <<EOF >/tmp/conftest.cpp
% g++ /tmp/conftest.cpp -I/usr/include/nvidia-current -L/usr/lib/nvidia-current -lGL -o /tmp/conftest
% ldd /tmp/conftest
linux-vdso.so.1 => (0x00007fff217ff000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f4673b5f000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f467384b000)
:
:
%
% file -L /usr/lib/libGL.so.1 /usr/lib/nvidia-current/libGL.so.1
/usr/lib/libGL.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped
/usr/lib/nvidia-current/libGL.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
Regards
Harri
Have you run "ldconfig" after doing the change? What's the output of "ldconfig -p | grep libGL.so.1"?
Of course I ran ldconfig (as root).
# ldconfig -p | grep libGL.so.1
libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1
libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1
http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11607.html AFAICS the issue is still unresolved. What would be your suggestion? Is there some configure option to tell ldconfig or ld.so to ignore the OS ABI tags? Regards Harri
I have another one in the same genre, but without the ABI tag messages.
$ ldd /usr/local/bin/ffmpeg
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavutil.so.49: no version
information available (required by /usr/local/bin/ffmpeg)
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavformat.so.52: no
version information available (required by /usr/local/bin/ffmpeg)
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavutil.so.49: no version
information available (required by /usr/local/lib/libswscale.so.0)
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavutil.so.49: no version
information available (required by /usr/local/lib/libavdevice.so.52)
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavformat.so.52: no
version information available (required by
/usr/local/lib/libavdevice.so.52)
/usr/local/bin/ffmpeg: /usr/lib/i686/cmov/libavutil.so.49: no version
information available (required by /usr/local/lib/libavcodec.so.52)
linux-gate.so.1 => (0xb7f36000)
libpostproc.so.51 => not found
libswscale.so.0 => /usr/local/lib/libswscale.so.0 (0xb7eff000)
libavdevice.so.52 => /usr/local/lib/libavdevice.so.52 (0xb7ef4000)
libavformat.so.52 => /usr/lib/i686/cmov/libavformat.so.52 (0xb7e55000)
libavcodec.so.52 => /usr/local/lib/libavcodec.so.52 (0xb7681000)
libavutil.so.49 => /usr/lib/i686/cmov/libavutil.so.49 (0xb7672000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb764c000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7632000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74d7000)
libdc1394.so.22 => /usr/lib/libdc1394.so.22 (0xb746a000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb73a8000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb72b9000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb72ab000)
libavcodec.so.51 => /usr/lib/i686/cmov/libavcodec.so.51 (0xb6d5a000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6d45000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6d41000)
libfaad.so.0 => /usr/lib/libfaad.so.0 (0xb6d02000)
libgsm.so.1 => /usr/lib/libgsm.so.1 (0xb6cf5000)
libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb6cad000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6bb2000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6b89000)
/lib/ld-linux.so.2 (0xb7f37000)
libraw1394.so.8 => /usr/lib/libraw1394.so.8 (0xb6b83000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb6b7a000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6b77000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6b5f000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6b5c000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb6b57000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6b52000)
that's an ffmpeg version I compiled myself, as I see it the errors are
about "second degree" dependency (linked by a library linked by
ffmpeg). All the libraries you see complaints about are actually part
of the ffmpeg source tree and are thus installed in /usr/local.
$ LD_LIBRARY_PATH=/usr/local/lib ldd /usr/local/bin/ffmpeg
linux-gate.so.1 => (0xb7f8a000)
libpostproc.so.51 => /usr/local/lib/libpostproc.so.51 (0xb7f79000)
libswscale.so.0 => /usr/local/lib/libswscale.so.0 (0xb7f4a000)
libavdevice.so.52 => /usr/local/lib/libavdevice.so.52 (0xb7f3f000)
libavformat.so.52 => /usr/local/lib/libavformat.so.52 (0xb7e42000)
libavcodec.so.52 => /usr/local/lib/libavcodec.so.52 (0xb766e000)
libavutil.so.49 => /usr/local/lib/libavutil.so.49 (0xb765d000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7631000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7617000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74bc000)
libdc1394.so.22 => /usr/lib/libdc1394.so.22 (0xb744f000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb738d000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb729e000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb728f000)
libz.so.1 => /usr/lib/libz.so.1 (0xb727a000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7276000)
libfaad.so.0 => /usr/lib/libfaad.so.0 (0xb7237000)
libgsm.so.1 => /usr/lib/libgsm.so.1 (0xb722a000)
libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb71e3000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb70e7000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb70be000)
/lib/ld-linux.so.2 (0xb7f8b000)
libraw1394.so.8 => /usr/lib/libraw1394.so.8 (0xb70b8000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb70af000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb70ad000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7094000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7091000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb708c000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7087000)
Are there any news about this? Is this unique to eglibc? Regards Harri
AFAICS the mesa folks don't rely upon the os abi tag anymore: https://bugs.freedesktop.org/show_bug.cgi?id=26663 Regards Harri
severity 572895 tags 572895 + upstream quit Harald Dunkel wrote: Thanks. I think this is still a bug (priority between LD_LIBRARY_PATH and .note.ABI-tag makes .note.ABI-tag much less useful than it could be), but it's a complex issue, so setting severity accordingly. Regards, Jonathan
Sorry to say, but I doubt that it is reasonable to set a bug to "wishlist", just because the OS ABI tag issue is complex. This does not help. My suggestion is to keep things simple. Since mesa doesn't need it anymore, are there any other packages in x86/amd64 that cannot follow the documented priority scheme as described in ld.so(8) and therefore require the OS ABI tag? Regards Harri