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) How reproducible: Always
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 symlinks. 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
Re: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126422#c2 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. http://www.coin3d.org) applications: * 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. https://bugzilla.fedora.us/show_bug.cgi?id=1786 https://bugzilla.fedora.us/show_bug.cgi?id=2021] 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.