Red Hat Bugzilla – Bug 126422
dlopen opening of GL and Xmu fails
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
While QA'ing Amarok media player at fedora.us (
https://bugzilla.fedora.us/show_bug.cgi?id=1318 ), I've found that Qt
fails to resolve OpenGL symbols, which causes the player to terminate
abruptly when enabling certain graphical analyzers:
Unable to resolve GL/GLX symbols - please check your
GL library installation.
OpenGL in Qt was working fine in FC1. In the qt.spec changelog I see
that Qt was reconfigured to "use dlopen, instead of linking with
OpenGL libraries directly" early this year.
This is now broken, because Qt's QLibrary loader searches for lib*.so
files only and hence doesn't find libGL.so.1 and would need the
libGL.so -> libGL.so.1 softlink in the optional "xorg-x11-devel"
package. Additionally, the dlopen_opengl change makes Qt fail on
libXmu.so, too, which is another link available in xorg-x11-devel:
Unable to resolve Xmu symbols - please check your
Xmu library installation.
The temporary work-around for any users who run into this is:
# ln -s /usr/X11R6/lib/libGL.so.1 /usr/lib/libGL.so
# ln -s /usr/X11R6/lib/libXmu.so.6 /usr/lib/libXmu.so
A theoretical [untested] fix would be to make
qt-x11-free-3.3.2/src/opengl/qgl_x11.cpp load "libGL.so.1" and
"libXmu.so.6" instead of "GL" and "Xmu".
Version-Release number of selected component (if applicable):
qt-3.3.2-2 (FC2) and qt-3.3.2-7 (FC Development)
Anvil, is this related to the trouble you ran into earlier?
yes, a temporary workaround is adding symlinks to libXmu and libGL
here or just installing of devel packages, which already include the
I will take a look here how this problem should be fixed.
it's fixed in qt-3.3.3-3. Thanks for your report
This does not help when using 3rd party libGL.so.1's at runtime but
using Mesa's libGL.so at link time (RH's standard procedure for using
3rd party libGL's)
In these cases, Qt will dlopen libGL.so instead of libGL.so.1, i.e.
Mesa will be used instead of the 3rd-Party libGL-Implementation.
Additional problems will occur if mixing GL-based libaries with Qt.
For example, this bug breaks Coin/SoQt-based (cf.
* Coin dlopens libGL.so.1 => 3rd party libGL
* SoQt uses QtGL widgets, i.e. it dlopens libGL.so => Mesa libGL
=> Any Coin/SoQt based application will fail on FC2.
[Coin and SoQt are part of FE cf.
IMO, this bug should be fixed for FC2 and Fedora Legacy should
consider to incorporate the corresponding patch
(qt-x11-free-3.3.3-gl.patch) for FC1.
Unfortunately, RH does not seem to allow me to reopen this bug
otherwise I now would have done so.
I think it may be worth fixing, but lets see if we have any other qt
patches queued for FC2 update first.
It's a bad idea to have mixed libGL there (libGL.so from mesa an
libGL.so.1 from 3rd party), it wont work. I don't think it's a bug here
You are complete wrong.
It's perfectly legal, correct and widely-used to mix GL, GLX and QTGL
calls in libraries.
It's also perfectly legal to link against different libraries at
run-time and at link-time.
It's your qt package's which is broken.
The fix from comment 3 is right and implements in qt-3.3.3-3.src.rpm
what I suggested at the bottom of the original bug report (just that
it also touches qlibrary.cpp which is necessary). Closing this as
NOTABUG is bad, but I won't reopen just to change that.