please bump the libGL.so.1.0.0 stub filename to libGL.so.1.7.0
Closed this issue · 6 comments
The libGL stub library filename is currently libGL.so.1.0.0 which is "lower" than the filename used by other previous implementations providing the libGL.so.1 SONAME.
If for whatever reason the libGL.so.1.X.Y from another implementation is left in the corresponding library directory alongside libGL.so.1.0.0 from libglvnd, ldconfig will happily update the libGL.so.1 symlink to point the "newest" version, i.e. the file with the "highest" filename version and SONAME libGL.so.1
This will result in an ancient pre-glvnd libGL.so.1 being used on a glvnd system - which will not work.
See e.g. https://bugs.debian.org/879041 for a related bug that lead me to this issue.
It can easily be demonstrated (in a throw-away chroot) by manually putting both a new and an old implementation in /usr/lib, ensuring that libGL.so.1.0.0 has a newer timestamp than libGL.so.1.2.0, and that libGL.so.1 points to the libglvnd variant:
# ls -l libGL.*
lrwxrwxrwx 1 root root 14 Jan 26 02:05 libGL.so.1 -> libGL.so.1.0.0
-rw-r--r-- 1 root root 567624 Jan 26 02:02 libGL.so.1.0.0
-rw-r--r-- 1 root root 463424 Jan 26 02:01 libGL.so.1.2.0
# ldconfig
# ls -l libGL.*
lrwxrwxrwx 1 root root 14 Jan 26 02:06 libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 567624 Jan 26 02:02 libGL.so.1.0.0
-rw-r--r-- 1 root root 463424 Jan 26 02:01 libGL.so.1.2.0
Since the libglvnd libGL.so.1.0.0 is supposed to be a successor to all the pre-glvnd implementations,
it should come with a filename that sorts later than all the previous ones, s.t. it takes precendence in case something old is leftover from older implementations.
libGL.so.1.7.0 is a suggestion since it is greater than all previous filenames I could find in Debian, but if there is something else that was in use on a different distro, feel free to bump even further.
On Debian I could find the following filenames being used in the past:
- fglrx drivers: libGL.so.1.2
- libgl1-mesa-glx: libGL.so.1.2
- libgl1-mesa-glx: libGL.so.1.2.0
- libgl1-mesa-swx11: libGL.so.1.5.060401
- libgl1-mesa-swx11: libGL.so.1.5.08005
- libgl1-mesa-swx11: libGL.so.1.6.0
In libtool notiation the change to libGL.so.1.7.0 canbe achieved by using -version-info 8:0:7 (instead of 1) in src/GL/Makefile.am
@anbe42 - Can you give more details on how you ran into that scenario? Was that entirely within distro packages, or from a combination of distro packages with something else?
I only debugged the issue ... I don't know how the user ran into the issue (probably mixing Debian distro packages of the NVIDIA driver with nvidia-installer .run packages), but in the end there was a distro-controlled libGL.so.1.0.0 and an "other" libGL.so.1.2.0 (which probably stems from a distro package as well, but was at some backup location managed by some non-distro package script at the time the corresponding distro-package got removed and was later restored to its original location) with the libGL.so.1 symlink pointing to libGL.so.1.2.0.
Dealing with the packaging of the NVIDIA drivers for Debian for years I know how fragile it is to clean up after mixing upstream and distro installation of things that want to claim libGL.so.1 - and having a libGL.so.1.0.0 filename sorting before the things it wants to replace is not going to help in case something unexpected was forgotten and never properly cleaned up.
My main worry would be of papering over some other packaging-related bug, but it sounds like that's not the case here.
Anyway, I can't think of any harm in bumping the version number in the filename, if it makes it more resilient to random problems like this.
I think another case where libglvnd currently "fails" independent from any vendor or distribution installation scripts is plain user compilation and installation to /usr/local, if there is already a pre-libglvnd MESA in /usr/local.
Which means the other libraries could use a filename version bump as well.
Let's see what happens if I build mesa-13.0.6, libglvnd-1.0.0, mesa-17.3.3 (these are the versions we have in Debian stable and unstable) with just a plain ./configure call (mesa-17.3.3 was configured with ./configure --enable-libglvnd --with-gallium-drivers=svga,swrast since I didn't bother too much for solving the llvm dependency for r600) and install them with make install DESTDIR=/tmp/FOO .
I didn't test whether anything of these works at all, since I was only interested in the content of usr/local/lib:
$ ls -la usr/local/lib/lib*GL*.so.*
lrwxrwxrwx 1 u g 15 Jan 27 02:07 usr/local/lib/libEGL.so.1 -> libEGL.so.1.0.0
-rwxr-xr-x 1 u g 129904 Jan 27 02:07 usr/local/lib/libEGL.so.1.0.0
lrwxrwxrwx 1 u g 20 Jan 27 02:09 usr/local/lib/libEGL_mesa.so.0 -> libEGL_mesa.so.0.0.0
-rwxr-xr-x 1 u g 1262760 Jan 27 02:09 usr/local/lib/libEGL_mesa.so.0.0.0
lrwxrwxrwx 1 u g 14 Jan 27 02:11 usr/local/lib/libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x 1 u g 731696 Jan 27 02:07 usr/local/lib/libGL.so.1.0.0
-rwxr-xr-x 1 u g 3444648 Jan 27 02:05 usr/local/lib/libGL.so.1.2.0
lrwxrwxrwx 1 u g 21 Jan 27 02:09 usr/local/lib/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 u g 54416 Jan 27 02:07 usr/local/lib/libGLESv1_CM.so.1.0.0
-rwxr-xr-x 1 u g 26824 Jan 27 02:09 usr/local/lib/libGLESv1_CM.so.1.1.0
lrwxrwxrwx 1 u g 18 Jan 27 02:09 usr/local/lib/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rwxr-xr-x 1 u g 57312 Jan 27 02:09 usr/local/lib/libGLESv2.so.2.0.0
lrwxrwxrwx 1 u g 15 Jan 27 02:07 usr/local/lib/libGLX.so.0 -> libGLX.so.0.0.0
-rwxr-xr-x 1 u g 128528 Jan 27 02:07 usr/local/lib/libGLX.so.0.0.0
lrwxrwxrwx 1 u g 20 Jan 27 02:09 usr/local/lib/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rwxr-xr-x 1 u g 2895992 Jan 27 02:09 usr/local/lib/libGLX_mesa.so.0.0.0
lrwxrwxrwx 1 u g 22 Jan 27 02:07 usr/local/lib/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
-rwxr-xr-x 1 u g 773208 Jan 27 02:07 usr/local/lib/libGLdispatch.so.0.0.0
lrwxrwxrwx 1 u g 18 Jan 27 02:07 usr/local/lib/libOpenGL.so.0 -> libOpenGL.so.0.0.0
-rwxr-xr-x 1 u g 235912 Jan 27 02:07 usr/local/lib/libOpenGL.so.0.0.0
The timestamps correspond to:
- 02:05 make install in mesa-13.0.6
- 02:07 make install in libglvnd-1.0.0
- 02:09 make install in mesa-17.3.3
- 02:11 ldconfig /tmp/FOO/usr/local/lib
Obviously I didn't configure mesa-17.3.3 correctly for glvnd since it still built libGLES* and overwrote the corresponding libraries from libglvnd - but that's not the point here.
For libEGL.so.1 and libGLESv2.so.2 both MESA and libglvnd use the same filename version, so no action is needed.
For libGL.so.1 we see that ldconfig claimed the link to point to libGL.so.1.2.0 from mesa-13.0.6 instead of libglvnd.
For libGLESv1_CM.so.1 we again have different filenames in mesa (libGLESv1_CM.so.1.1.0) and libglvnd (libGLESv1_CM.so.1.0.0). Which does not bother Debian at all since it has already disabled GLES1. But for completeness I'd suggest a filename version bump here, too: -version-info 3:0:2 to produce libGLESv1_CM.so.1.2.0
I didn't do a search whether older versions of MESA used different filenames for the EGL/GLES libraries.
Based on the above, it sounds like we'd want to change:
- libGL.so.1.0.0 -> libGL.so.1.7.0
- libGLESv1_CM.so.1.0.0 -> libGLESv1_CM.so.1.2.0
- libGLESv2.so.2.0.0 -> libGLESv2.so.2.1.0
- libEGL.so.1.0.0 -> libEGL.so.1.1.0
I think that would ensure at least consistent results if you installed libglvnd on a system that already had a non-libglvnd version of Mesa. Of course, the libglvnd libraries aren't going to be able to use a non-libglvnd Mesa, but that's still better than ending up with a mix of the two.
Looks good to me :-)