Bug 126422 - dlopen opening of GL and Xmu fails
dlopen opening of GL and Xmu fails
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-21 10:41 EDT by Michael Schwendt
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-16 09:50:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2004-06-21 10:41:37 EDT
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
Comment 1 Warren Togami 2004-06-21 21:45:05 EDT
Anvil, is this related to the trouble you ran into earlier?
Comment 2 Ngo Than 2004-06-22 05:48:04 EDT
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.
Comment 3 Ngo Than 2004-08-18 09:38:56 EDT
it's fixed in qt-3.3.3-3. Thanks for your report
Comment 4 Ralf Corsepius 2004-09-16 00:27:54 EDT
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.
Comment 5 Warren Togami 2004-09-16 04:06:25 EDT
I think it may be worth fixing, but lets see if we have any other qt
patches queued for FC2 update first.
Comment 6 Ngo Than 2004-09-16 09:50:03 EDT
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
Comment 7 Ralf Corsepius 2004-09-16 10:13:32 EDT
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.
Comment 8 Michael Schwendt 2004-09-16 10:42:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.