Bug#530772: libgl1-mesa-glx: Recent library update broke starsuite8 (openoffice 2 variant) and glxinfo
Julien Cristau wrote:
....
Do they look like they came from fglrx?
They don't look like they come from libgl1-mesa-glx in any case:
$ dpkg -c /org/ftp.root/debian/pool/main/m/mesa/libgl1-mesa-glx_7.0.3-7_i386.deb | grep libGL.so.1.2
-rw-r--r-- root/root 397196 2008-12-14 06:02 ./usr/lib/libGL.so.1.2
lrwxrwxrwx root/root 0 2008-12-14 06:02 ./usr/lib/libGL.so.1 -> libGL.so.1.2
Does apt-get install --reinstall libgl1-mesa-glx fix the problem?
It would be mighty handy if there is consolidated tool to figure out
the origin of these X library files.
(Now I am beginning to realize why it was
so difficult to figure out which package provides libGL.*.
I tried by searching Debian packages, but was not so sure.
From what you suggest, it seems to me that there are non-Debian packages (or
deb packages that are prepared by a third party) that provides the libraries
in question. Hmm...)
Yes, it's a mess. The debian packages for fglrx and nvidia use
dpkg-divert to install their libGL and move mesa's out of the way. I
don't know what the vendor-provided installers do, but it's quite
possible they don't bother with this and just replace the already
installed libGL.
Thanks for following up!
Cheers,
Julien
Short Answer:
Per your suggestion, I sought to restore libGL and
once it is done, all is well.
Long Answer:
(1) I found out that the libGL in question is indeed
from fglrx.
(2) Will overwriting by re-installing libgl1-mesa-glx fix it?
Well, I got curious at the mention of dpkg-divert, and
ran "aptitude remove fglrx-glx" to see if it restores
the libGL libary.
Anyway, "aptitude remove fglrx-glx" restored the
libGL to that of libgl1-mesa-glx. Great.
(I wonder though, if the saved library
is actualy updated by another release of libgl1-mesa-glx
while the ones from fglrx is used.
Will dpkg/apt-get realize this and download a newer
version of libgl1-mesa-glx? This was not the case this time.)
(3) After this, starsuite and glxinfo work like a charm!
(4) My summary. We may need a separate tool to check
the sanity of application setup and library files...
Details.
(1) My libGL were from fglrx.
On a different PC, I ran the following command like you did to figure
out the size, etc. of libGL
ishikawa@w3:~/Desktop$ dpkg -c fglrx-glx_8-12-4_i386.deb | grep libGL
-rw-r--r-- root/root 556108 2009-01-12 09:53 ./usr/lib/libGL.so.1.2
lrwxrwxrwx root/root 0 2009-01-12 09:53 ./usr/lib/libGL.so.1 -> libGL.so.1.2
The info matched those of libGL.so.1.2 I reported earlier.
The libGL files are from fglxrx-glx package.
(2) Will overwriting by re-installing libgl1-mesa-glx fix it?
I ran "aptitude remove fglrx-glx" to see if libGL files are
restored properly. Do diversion work as expected? (Yes they did)
See the following script.
Script started on ...
ishikawa@duron$ LANG=C
ishikawa@duron$ LC_ALL=CA
ishikawa@duron$ ls -l /usr/lib/libGL.so*
lrwxrwxrwx 1 root root 10 Jan 5 11:29 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 Feb 20 01:07 /usr/lib/libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 556108 Jan 12 09:53 /usr/lib/libGL.so.1.2
ishikawa@duron$ dpkg -l | grep fglrx
rc fglrx-4-3-0 8.25.18-2 X Window display driver for the ATI graphics
ic fglrx-6-8-0 8.28.8-2 X Window display driver for the ATI graphics
ii fglrx-amdcccle 1:8-12-4 control panel for the non-free AMD/ATI r5xx,
rc fglrx-atieventsd 1:8-7-3 external events daemon for the non-free AMD/
ii fglrx-control 1:8-12-4 control panel for the non-free AMD/ATI r5xx,
ii fglrx-driver 1:8-12-4 non-free AMD/ATI r5xx, r6xx, r7xx display dr
ii fglrx-glx 1:8-12-4 proprietary libGL for the non-free AMD/ATI r
ii fglrx-kernel-src 1:8-12-4 kernel module source for the non-free AMD/AT
ii fglrx-modules-2.6.25-2-486 2.6.25+8-6-2 Display driver for AMD/ATI Radeon and FireGL
rc fglrx-modules-2.6.25-2-686 2.6.25+8-6-2 Display driver for AMD/ATI Radeon and FireGL
ii fglrx-source 1:8-12-4 kernel module source for the non-free AMD/AT
ishikawa@duron$ su
Password:
duron:/home/ishikawa/tmp.dir# aptitude remove fglrx-glx
Reading package lists... Done
Building dependency tree...
Reading state information... Done
Reading extended state information...
Initializing package states.... Done
Reading task descriptions... Done
The following packages will be REMOVED:
fglrx-glx
0 packages upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
Need to get 0B of archives. After unpacking 651kB will be freed.
Writing extended state information... Done
(Reading database ... 165323 files and directories currently installed.)
Removing fglrx-glx ...
Removing `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-glx'
Removing `diversion of /usr/lib/libGL.so.1 to /usr/lib/fglrx/diversions/libGL.so.1 by fglrx-glx'
Removing `diversion of /usr/lib/xorg/modules/extensions/libdri.so to /usr/lib/fglrx/diversions/libdri.so by fglrx-driver'
Reading package lists... Done
Building dependency tree...
Reading state information... Done
Reading extended state information...
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done
duron:/home/ishikawa/tmp.dir# ls -l /usr/lib/libGL*
lrwxrwxrwx 1 root root 10 Jan 5 11:29 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 Jan 5 11:29 /usr/lib/libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 397196 Dec 14 15:02 /usr/lib/libGL.so.1.2
-rw-r--r-- 1 root root 696764 Dec 14 15:02 /usr/lib/libGLU.a
lrwxrwxrwx 1 root root 11 Jan 5 11:29 /usr/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root 20 Jan 5 11:29 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.070004
-rw-r--r-- 1 root root 532152 Dec 14 15:02 /usr/lib/libGLU.so.1.3.070004
duron:/home/ishikawa/tmp.dir# exit
exit
(3) glxinfo and starsuite8 work now!
ishikawa@duron$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
...
...
...
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 0 32 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 0 32 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x61 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon
ishikawa@duron$ soffice
Entity: line 1: parser error : Start tag expected, '<' not found
^_
^
ishikawa@duron$ soffice (I revert the setting of use of opengl inside ss8)
ishikawa@duron$ soffice
parser error et al was caused by a corrupt configuration file of a sort
when I tried to disable the use of openGL within startsuite8
(Tools->View->3D-> Use OpenGL ).
(4) My summary. We may need a separate tool to check
the sanity of application setup and library files...
This is beyond the scope of this bug report alone, but
given the number of people who are affected in a similar manner
after system upgrade (and some resort to the total re-install of
their distribution!. Googling shows us these reports.), I think a remedy to check the
library configuration is required for the benefit of community.
Here the problem is that the use of the package or application is not
quite tied to the state of historical order of the debian packages
installation.
This is probably beyond what a packaging system can enforce or
properly handle, though.
In my case, the installation history was something like this.
a. Installed ordinary Mesa OpenGL
(and use ATI driver for X11.
ATI driver eventually use radeon, a submodule.)
b. Installed flgrx (with its own version of OpenGL)
(and use flgrx driver for X11 for a few minutes after editing
/etc/X11/xorg.conf)
c. Found flgrx is slow on my setup and
edits /etc/X11/xorg.conf to use ATI driver again.
But I did so *WITHOUT* removing flgrx.
Just re-editing will suffice, won't it?
WRONG, A PROBLEM!
libGL is out of sync with the usage of ordinary ATI (radeon)
driver...
d. Until mid-May, the above configuration (slightly out of sync)
worked, but after mid-May when I upgraded
my install using "aptitude {update| upgrade},
glxinfo and starsuite8 won't run, and this was *suddenly to my eyes*.
e. Removed "flgrx-glx" using "aptitude remove flgrx-glx" and
once /usr/lib/libGL.* are restored to the ones installed
in step (a), glxinfo and starsuite8 work again.
I repeat that this is probably beyond what a packaging system can do
except:
(a) Maybe we can build a sanity-checker of application configuration
before starting, in this case, X. (Or at least as a diagnostic
aid when a problem like this bites us.)
Check Xorg.conf and check the main graphics driver and
if known conflicts with major libraries (in this case libGL*)
check that they are indeed coming from the expected libraries.
(b) Automate configuration of applications so that no inconsistency
is introduced.
In this case, Xorg.conf is always automatically re-generated or
checked after the manual configuration for inconsistency, etc..
I think it will be nifty, but it is too much to expect such
an ideal situation.
In the case of nvidia and flgrx drivers, it seems to me that
library compatibility problems are so rampant (I found many mentions
of broken opengl-related programs including
staroffice/starsuite/openoffice after an upgrade when I searched google.)
So a simple program to check the library compatibility with the user's
graphics driver might go a long way.
I can try writing one, but aside from libGL,
which X library files should be checked with such a
script to make sure that the main graphics driver and such library
files are compatible?
Drivers used by applications. | libGL and friends need to be ...
----------------------------------------------------
drivers that assume mesa .| must be mesa-based libGL and others.
drivers that assume flgrx .| must be flgrx-based libGL, etc..
drivers that assume nvidia .| must be nvidia-based libGL, etc..
Such checking can be done statically by a separate script or
dynamically by a library entry point.
The checking can be elaborate or very simple.
We can check the (hidden/static) symbol inside a library,
or the size/md5 checksum of a library for simplicity's sake.
To wit, an old nvidia library seems to check the sanity at runtime.
On a different PC, I have an old nvidia graphics card, and Debian on
that machine uses NVidia proprietary driver.
Section "Device"
# Driver "nv"
Identifier "nVidia Corporation NV11GL [Quadro2 MXR/EX/Go]"
Driver "nvidia"
EndSection
strings - /usr/lib/libGL.so | grep NV
....
.... at the end ...
....
NV-GLX
NVIDIA: failed to execute '%s': %s.
Error: API mismatch: the NVIDIA kernel module has version %s,
but this NVIDIA driver component has version %s. Please make
sure that the kernel module and all NVIDIA driver components
Error: API mismatch: this NVIDIA driver component has version
%s, but the NVIDIA kernel module's version does not match.
Please make sure that the kernel module and all NVIDIA driver
NVIDIA: failed to load the NVIDIA kernel module.
NVIDIA: could not open the device file %s (%s).
The nvidia library checks that the kernel module needs to be in sync with
this library and if not aborts.
Also, it prints out very easy-to-understand message so that
I come to learn that I need to update my installation.
My 2 cents worth.
If something like this can be written for libGL coming from mesa/ati/whatever,
we can reduce the collective man-hours lost due to the
incompatibilities.
Thank you again for your time, and
thank you for reading this far :-)
Happy Hacking
CI
--
int main(void){int j=2008;/*(c)2008 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="b>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */
Reply to: