Does fglrx's libGL.so.1.2 have wrong soname?

[chrisr]

I have just discovered that my fglrx installation under Fedora 8 was using Mesa's version of libGL.so.1.2 instead of ATI's. The underlying reason for this seems to be that all my OpenGL applications are looking for a library called libGL.so.1, whereas ATI's library advertises itself as libGL.so.1.2. Basically, ATI seems to have built its library without setting its soname to "libGL.so.1".

Linking a simple dynamic executable against ATI's libGL gives the following:

$ ldd -r ./a.out 
        linux-gate.so.1 =>  (0xb7f35000)
        libGL.so.1.2 => /usr/lib/fglrx/libGL.so.1.2 (0xb7e96000)
        libc.so.6 => /lib/libc.so.6 (0x443d3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x44560000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x47d1f000)
        /lib/ld-linux.so.2 (0x443b4000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x47c03000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x44599000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x47bff000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x47d01000)
        libdl.so.2 => /lib/libdl.so.2 (0x44559000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x445a2000)

whereas something like glxinfo expects to find the following:

$ ldd `which glxinfo`
        linux-gate.so.1 =>  (0xb7f7b000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7edc000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7e6d000)
        libc.so.6 => /lib/libc.so.6 (0x443d3000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x47c03000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x44560000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x47d1f000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x44fe8000)
        libm.so.6 => /lib/libm.so.6 (0x4452e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x44f62000)
        /lib/ld-linux.so.2 (0x443b4000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x47bff000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x47d01000)
        libdl.so.2 => /lib/libdl.so.2 (0x44559000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x44599000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x445a2000)

I have (hopefully!) sorted this mess out by moving Mesa's libGL.so.1.2 library out of harm's way, and then creating a symbolic link in /usr/lib:

$ ls -als /usr/lib/libGL.so.1
0 lrwxrwxrwx 1 root root 18 2008-01-12 23:58 /usr/lib/libGL.so.1 -> fglrx/libGL.so.1.2

I installed fglrx from binary packages, and so am slightly surprised to be needing to get my hands dirty like this. Does anyone have any thoughts, please?

Cheers,
Chris

[givemesugarr]

I have just discovered that my fglrx installation under Fedora 8 was using Mesa's version of libGL.so.1.2 instead of ATI's. The underlying reason for this seems to be that all my OpenGL applications are looking for a library called libGL.so.1, whereas ATI's library advertises itself as libGL.so.1.2. Basically, ATI seems to have built its library without setting its soname to "libGL.so.1".

Linking a simple dynamic executable against ATI's libGL gives the following:

$ ldd -r ./a.out 
        linux-gate.so.1 =>  (0xb7f35000)
        libGL.so.1.2 => /usr/lib/fglrx/libGL.so.1.2 (0xb7e96000)
        libc.so.6 => /lib/libc.so.6 (0x443d3000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x44560000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x47d1f000)
        /lib/ld-linux.so.2 (0x443b4000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x47c03000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x44599000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x47bff000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x47d01000)
        libdl.so.2 => /lib/libdl.so.2 (0x44559000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x445a2000)

whereas something like glxinfo expects to find the following:

$ ldd `which glxinfo`
        linux-gate.so.1 =>  (0xb7f7b000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7edc000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7e6d000)
        libc.so.6 => /lib/libc.so.6 (0x443d3000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x47c03000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x44560000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x47d1f000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x44fe8000)
        libm.so.6 => /lib/libm.so.6 (0x4452e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x44f62000)
        /lib/ld-linux.so.2 (0x443b4000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x47bff000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x47d01000)
        libdl.so.2 => /lib/libdl.so.2 (0x44559000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x44599000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x445a2000)

I have (hopefully!) sorted this mess out by moving Mesa's libGL.so.1.2 library out of harm's way, and then creating a symbolic link in /usr/lib:

$ ls -als /usr/lib/libGL.so.1
0 lrwxrwxrwx 1 root root 18 2008-01-12 23:58 /usr/lib/libGL.so.1 -> fglrx/libGL.so.1.2

I installed fglrx from binary packages, and so am slightly surprised to be needing to get my hands dirty like this. Does anyone have any thoughts, please?

Cheers,
Chris

this was a problem of catalyst 7.11 and ati-driver-8.42. wrong soname for the lib. the workaround was to symlink the libGL.so.1 to the libGL.so.1.2 manually. and yes it has already been corrected in 7.12 as well as the memory leak bug that were also present in 8.42 and 7.12. if you've already installed the 7.11 and is working then stay with it until 8.1, since i don't think that you'll have to wait long for it to get out. usually the releases come around the half of the month so it's almost there to grab and use.

[chrisr]

this was a problem of catalyst 7.11 and ati-driver-8.42. wrong soname for the lib.

Hmm, I'm sure I've had this problem ever since I successfully hacked fglrx to work on my FireGL laptop. Maybe that was 8.42...

it has already been corrected in 7.12 as well as the memory leak bug that were also present in 8.42 and 7.12.

Well that's good to hear. 7.12 was a complete disaster for me because the X server just hung while it tried to initialise. This could easily have been because it was trying to use the wrong libGL.so.1.

if you've already installed the 7.11 and is working then stay with it until 8.1, since i don't think that you'll have to wait long for it to get out.

Heh, I fully intend to stick with my hacked 7.11 driver for now, because 7.12 was also incapable of supporting 1680x1050 resolution! Now THAT is a bug that I really want fixed in 8.1. OpenGL game-play with 7.11 is also a lot smoother now that I've installed the correct libGL library, although the Xserver still seg-faults every time xine finishes XVideo playback.