fedora core 1 bugzilla bug 110124

[bartm]

Is someone working on fedora core 1 bug 110124, alias nvidiadia? I think the information written by Mike A. Harris deserves some attention here...
https://bugzilla.redhat.com/bugzilla....cgi?id=110124

(For those using searching this forum on keywords, I copy some keywords of the bug report below.)

xscreensaver
nvidiadri
110124
binary installer
libglx.a
Mesa libGL
XFree86
nv
OpenGL
GLX
Conflicts: XFree86-Mesa-libGL
LD_PRELOAD
/etc/profile.d
/usr/lib/libGL*
TLS
/usr/lib/libGL.so.*
Xlib: extension "XFree86-DRI" missing
rm -f /usr/X11R6/lib/tls/libGL*
rpm -e --nodeps XFree86-Mesa-libGL

[bartm]

The alias is nvidiadri, sorry.

[zander]

The NVIDIA installer aims to be distribution independent, it doesn't make sense for it to know about or attempt to uninstall distribution specific packages (RedHat/Fedora is a popular distribution, but doesn't qualify as a synonym for "the GNU/Linux operating system", nor does its installation mechanism represent the defacto operating system standard). The current nvidia-installer release does investigate and remove conflicting files from /usr/X11R6/lib/tls; earlier releases likely didn't since this installation location ignores and is in conflict with the Linux OpenGL ABI (http://oss.sgi.com/projects/ogl-sample/ABI/). Contrary to Mike's statement, nvidia-installer is an open-source (ftp://download.nvidia.com/XFree86/nvidia-installer/) application; developers external to NVIDIA could improve the application and submit patches, were they so inclined. Source RPMs are also available and can be used to build distribution specific packages (SuSE Linux builds and provides such packages). If RedHat had chosen to do so, it could have solved the problems described in the bug report.

[sphincter]

Unfortunately, while I use RH/Fedora, they've always been complete jerks when it comes to supporting anything that isn't completely OSS. If you report a problem with their distribution and a vendor's closed source driver, they always close it as "not a bug" and tell you to get support from the vendor. They won't even offer so much as a work around or try to gain compatibility even if it is a bug/packaging issue in their packages.

[zander]

Following up on the Linux OpenGL ABI conflict, I think Mike's comment on the conformance of /usr/X11R6/lib as the installation path for libGL.so.1 is valid. It's still unfortunate that RedHat chose this location, either ignorant of or accepting the problems with widely used drivers.

[sphincter]

What's even more unfortunate is that they're so convinced that they're right, they, in certain circumstances, seem to ignore the possibility that they might be wrong. Anyway, before this becomes a "let's bash RH" thread, I'll stop.

[zander]

I hold no grudge against RedHat and have no reason to "bash" them; flame wars don't enjoy the reputation of being productive, anyway, and pointing fingers doesn't solve problems. My initial comment on the bug report was merely intended to point out common misconceptions about NVIDIA's installation utility, nvidia-installer.

My memory didn't serve me well and I made the false claim (which I withdrew after re-reading the document) that the /usr/X11R6/lib installation path itself violates the Linux OpenGL ABI; this is not the case, as Mike also points out in his latest comment. He makes valid points with respect to the runtime linker and architecture specific optimizations and there is no denying that earlier versions of nvidia-installer falsely assume that no libGL will reside outside of /usr/lib. As a result, conflicting files are searched for in /usr/lib, only, and moved to /var/lib/nvidia to allow their restoration in the event that the NVIDIA driver is to be uninstalled. Consequently, any copies of libGL installed in /usr/X11R6/lib remain intact.

Even these older revisions of nvidia-installer place the appropriate NVIDIA libGL in /usr/lib/tls, however, which leaves the question why the libraries in /usr/X11R6/lib/tls have precedence, when they shouldn't:

[root@fedora root]# ldconfig -p | grep libGL.so
        libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/X11R6/lib/tls/libGL.so.1
        libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/libGL.so.1
        libGL.so (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so
        libGL.so (libc6) => /usr/lib/libGL.so

[root@fedora root]# ldd /usr/X11R6/bin/glxgears
        libGL.so.1 => /usr/X11R6/lib/tls/libGL.so.1 (0x00732000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00101000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00d20000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00147000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00cf7000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00bbc000)
        libdl.so.2 => /lib/libdl.so.2 (0x00d1b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00ba4000)

Either way, one can only hope that distributors such as RedHat and hardware vendors such as NVIDIA (as well as distributors/vendors among themselves) will find ways to coordinate their efforts more efficiently in the future.

[sphincter]

Originally posted by zander
Even these older revisions of nvidia-installer place the appropriate NVIDIA libGL in /usr/lib/tls, however, which leaves the question why the libraries in /usr/X11R6/lib/tls have precedence, when they shouldn't:

[root@fedora root]# ldconfig -p | grep libGL.so
        libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/X11R6/lib/tls/libGL.so.1
        libGL.so.1 (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/libGL.so.1
        libGL.so (libc6, hwcap: 0x8000000000000000) => /usr/lib/tls/libGL.so
        libGL.so (libc6) => /usr/lib/libGL.so

[root@fedora root]# ldd /usr/X11R6/bin/glxgears
        libGL.so.1 => /usr/X11R6/lib/tls/libGL.so.1 (0x00732000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00101000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00d20000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00147000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00cf7000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00bbc000)
        libdl.so.2 => /lib/libdl.so.2 (0x00d1b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00ba4000)

Either way, one can only hope that distributors such as RedHat and hardware vendors such as NVIDIA (as well as distributors/vendors among themselves) will find ways to coordinate their efforts more efficiently in the future.

I read an article about this awhile back. Basically, the lib search order is stored within the binary itself, so that's how the code was written and linked.

There are even some utilities out there for patching a binary to change the order, or even add new entries into the table.