Bug 126422

Summary:	dlopen opening of GL and Xmu fails
Product:	[Fedora] Fedora	Reporter:	Michael Schwendt <bugs.michael>
Component:	qt	Assignee:	Than Ngo <than>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2	CC:	anvil, gauret, rc040203, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-16 13:50:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael Schwendt 2004-06-21 14:41:37 UTC

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-22 01:45:05 UTC

Anvil, is this related to the trouble you ran into earlier?

Comment 2 Than Ngo 2004-06-22 09:48:04 UTC

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 Than Ngo 2004-08-18 13:38:56 UTC

it's fixed in qt-3.3.3-3. Thanks for your report

Comment 4 Ralf Corsepius 2004-09-16 04:27:54 UTC

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 08:06:25 UTC

I think it may be worth fixing, but lets see if we have any other qt
patches queued for FC2 update first.

Comment 6 Than Ngo 2004-09-16 13:50:03 UTC

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 14:13:32 UTC

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 14:42:30 UTC

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.