Bug #7452 “general: “Unable to resolve GL/GLX symbols message wh...” : Bugs : qt-x11-free package : Ubuntu

Revision history for this message

In Debian Bug tracker #266007, Ben Burton (bab) wrote on 2004-08-16: Re: Bug#266007: general: "Unable to resolve GL/GLX symbols message when starting OpenGL application"

#1

reassign 266007 libqt3c102-mt
thanks mate

Hi. This appears to be the same issue as #264928.

The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
this was fixed by the Qt maintainer. If you can't upgrade just yet,
installing xlibmesa-dev is a workaround solution.

Ben.

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-16:

#2

Hello Ben,

I use already Version 3:3.3.3.1 of the libqt3c102-mt!?!?

WR

On Monday 16 August 2004 12:07, you wrote:
> reassign 266007 libqt3c102-mt
> thanks mate
>
> Hi. This appears to be the same issue as #264928.
>
> The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
> this was fixed by the Qt maintainer. If you can't upgrade just yet,
> installing xlibmesa-dev is a workaround solution.
>
> Ben.

-------------------------------------------------------

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-16:

#3

Automatically imported from Debian bug report #266007 http://bugs.debian.org/266007

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-16:

#4

Message-ID: <E1BwdZR-0000WO-UU@localhost>
Date: Mon, 16 Aug 2004 11:14:41 +0200
From: Wolfgang Roemer <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: general: "Unable to resolve GL/GLX symbols message when starting OpenGL
application"

Package: general
Severity: serious
Justification: Unknown

Since upgrading my debian system on Aug. 16th, applications that use
OpenGL don't start anymore with the "Unable to resolve GL/GLX symbols" message.
Direct rendering is enabled and works well with glxgears for example.
The problem seems to be related to applications using Qt.

Special on my system is the usage of the proprietary nvidia driver for
XFree86.

-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.5
Locale: LANG=C, LC_CTYPE=C

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-16:

#5

Message-ID: <email address hidden>
Date: Mon, 16 Aug 2004 20:07:14 +1000
From: Ben Burton <email address hidden>
To: Wolfgang Roemer <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#266007: general: "Unable to resolve GL/GLX symbols message when starting OpenGL
application"

reassign 266007 libqt3c102-mt
thanks mate

Hi. This appears to be the same issue as #264928.

The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
this was fixed by the Qt maintainer. If you can't upgrade just yet,
installing xlibmesa-dev is a workaround solution.

Ben.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-16:

#6

Message-Id: <email address hidden>
Date: Mon, 16 Aug 2004 13:30:32 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>
Subject: Re: Bug#266007: general: "Unable to resolve GL/GLX symbols message when starting OpenGL
application"

Hello Ben,

I use already Version 3:3.3.3.1 of the libqt3c102-mt!?!?

WR

On Monday 16 August 2004 12:07, you wrote:
> reassign 266007 libqt3c102-mt
> thanks mate
>
> Hi. This appears to be the same issue as #264928.
>
> The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
> this was fixed by the Qt maintainer. If you can't upgrade just yet,
> installing xlibmesa-dev is a workaround solution.
>
> Ben.

-------------------------------------------------------

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-16:

#7

Hello Ben,

to be more precise:

I did not have any OpenGL problems with the older qt-3:3.3.2. The problem
started to occur with the new qt version!

I had a look at the "solution" that was proposed for Qt in the bug you
mentioned (#26492 ): The so-called solution makes everything worse: Instead
of search for a libGL, Qt will now search explicitly for a library called
libGL.so.1 which would be /usr/X11R6/lib/libGL.so.1.2 of the xlibmesa-gl
package. So if that package is installed Qt will find a mesa lib explicitly
searching for the DRI extension resulting in a "extension XFree86-DRI missing
on display ..." message if a NVIDIA proprietary driver is installed.

In fact I don't know exactly which change in the new Qt libary version 3:3.3.3
is responsible for the misbehaviour. I can just say for sure, that the
problem wasn't there with the Qt 3:3.3.2 because I develop with OpenGL all
day and it worked well for me since I got my computer. It is of course
possible that the problem does not come from the Qt library alone because the
last apt-get upgrade this morning (Monday, Aug. 16th) caused several packages
to be upgraded (e.g. a lot of stuff from KDE 3.3.0)

WR

On Monday 16 August 2004 12:07, Ben Burton wrote:
> reassign 266007 libqt3c102-mt
> thanks mate
>
> Hi. This appears to be the same issue as #264928.
>
> The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
> this was fixed by the Qt maintainer. If you can't upgrade just yet,
> installing xlibmesa-dev is a workaround solution.
>
> Ben.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-16:

#8

Message-Id: <email address hidden>
Date: Mon, 16 Aug 2004 16:51:35 +0200
From: Wolfgang Roemer <email address hidden>
To: Ben Burton <email address hidden>,
<email address hidden>
Subject: Re: Bug#266007: general: "Unable to resolve GL/GLX symbols message when starting OpenGL
application"

Hello Ben,

to be more precise:

I did not have any OpenGL problems with the older qt-3:3.3.2. The problem
started to occur with the new qt version!

I had a look at the "solution" that was proposed for Qt in the bug you
mentioned (#26492 ): The so-called solution makes everything worse: Instead
of search for a libGL, Qt will now search explicitly for a library called
libGL.so.1 which would be /usr/X11R6/lib/libGL.so.1.2 of the xlibmesa-gl
package. So if that package is installed Qt will find a mesa lib explicitly
searching for the DRI extension resulting in a "extension XFree86-DRI missing
on display ..." message if a NVIDIA proprietary driver is installed.

In fact I don't know exactly which change in the new Qt libary version 3:3.3.3
is responsible for the misbehaviour. I can just say for sure, that the
problem wasn't there with the Qt 3:3.3.2 because I develop with OpenGL all
day and it worked well for me since I got my computer. It is of course
possible that the problem does not come from the Qt library alone because the
last apt-get upgrade this morning (Monday, Aug. 16th) caused several packages
to be upgraded (e.g. a lot of stuff from KDE 3.3.0)

WR

On Monday 16 August 2004 12:07, Ben Burton wrote:
> reassign 266007 libqt3c102-mt
> thanks mate
>
> Hi. This appears to be the same issue as #264928.
>
> The fix is to upgrade your libqt3c102-mt to version 3:3.3.3-1, where
> this was fixed by the Qt maintainer. If you can't upgrade just yet,
> installing xlibmesa-dev is a workaround solution.
>
> Ben.

Revision history for this message

In Debian Bug tracker #266007, Ben Burton (bab) wrote on 2004-08-17:

#9

Hi,

> I had a look at the "solution" that was proposed for Qt in the bug you
> mentioned (#26492 ): The so-called solution makes everything worse: Instead
> of search for a libGL, Qt will now search explicitly for a library called
> libGL.so.1 which would be /usr/X11R6/lib/libGL.so.1.2 of the xlibmesa-gl
> package. So if that package is installed Qt will find a mesa lib explicitly
> searching for the DRI extension resulting in a "extension XFree86-DRI missing
> on display ..." message if a NVIDIA proprietary driver is installed.

I don't know enough about GL internals or how it works with proprietary
drivers to have any further (useful) comments to make. So I'm afraid I
must leave this to the Qt and/or GL people.

Ben.

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17: The build process of the debian qt lib seems to have changed

#10

Download full text (3.9 KiB)

Some further investigations:

The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built
with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the
dependency
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
        libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
        libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Use ldd on the new qt library (libqt3c102-mt, 3.3.3-2) you get:
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
        libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a3f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a48000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40b84000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

You'll notice that there is no "explicit" OpenGL d...

Some further investigations:

The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built 
with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the 
dependency
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
        libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
        libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Use ldd on the new qt library  (libqt3c102-mt, 3.3.3-2) you get:
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
        libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a3f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a48000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40b84000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

You'll notice that there is no "explicit" OpenGL dependency. The interesting 
file where the decision is made during compile time is

qgl_x11_p.h

There QT_DLOPEN_OPENGL is used to decide whether the dynamic usage of OpenGL 
should be chosen (resulting in QLibraryPrivate::loadLibrary (...) and so on) 
or whether Qt is directly linked to the OpenGL library and 
qt_resolve_gl_symbols (...) becomes an inline function always returning true. 
The old qt version provided used the second approach as the ldd output I 
posted indicates. The new version provided seems to have been built with the 
first approach resulting in problems concerning different OpenGL libraries 
always present on a system.

After all I still did not get a clue what exactly is going wrong because even 
when I ensure that the OpenGL library Qt will find is the correct one, I 
still get the error.

WR

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17: Trivial compile test

#11

Bytheway: Here is a simple program that is usable to test the qt behaviour:

// Standard C/C++
#include <stdio.h>

// Standard Qt
#include <qapplication.h>
#include <qgl.h>

int main (int argc, char* argv[])
{
QApplication a(argc,argv);

    if (QGLFormat::hasOpenGL() == false)
    {
      qWarning ("This system has no OpenGL support. Exiting.");
      return -1;
    }

printf ("Yout system has OpenGL support.\n");
return 0;
}

There is an interesting point during the linking as well: Normally, because as
I mentioned in my previous post the Qt library will dynamically search for
the OpenGL lib, there is no need to link against OpenGL:

g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt

This command succeeds as expected but crashes during runtime:

~/tests/debian_qt_bug> ./bug
Floating point exception

Linking against the OpenGL library explicitly creates an executable showing
the standard buggy behaviour:

g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt -lGL

~/tests/debian_qt_bug> ./bug
This system has no OpenGL support. Exiting.

WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#12

Message-ID: <email address hidden>
Date: Tue, 17 Aug 2004 17:39:47 +1000
From: Ben Burton <email address hidden>
To: Wolfgang Roemer <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#266007: general: "Unable to resolve GL/GLX symbols message when starting OpenGL
application"

Hi,

> I had a look at the "solution" that was proposed for Qt in the bug you
> mentioned (#26492 ): The so-called solution makes everything worse: Instead
> of search for a libGL, Qt will now search explicitly for a library called
> libGL.so.1 which would be /usr/X11R6/lib/libGL.so.1.2 of the xlibmesa-gl
> package. So if that package is installed Qt will find a mesa lib explicitly
> searching for the DRI extension resulting in a "extension XFree86-DRI missing
> on display ..." message if a NVIDIA proprietary driver is installed.

I don't know enough about GL internals or how it works with proprietary
drivers to have any further (useful) comments to make. So I'm afraid I
must leave this to the Qt and/or GL people.

Ben.

Revision history for this message

In Debian Bug tracker #266007, Martin Gerhard Loschwitz (martin-loschwitz) wrote on 2004-08-17: Downgrading 266007 -- WHAT THE FUCK?!

#13

severity 266007 important
thanks

--
.''`. Martin Loschwitz Debian GNU/Linux developer
: :' : <email address hidden> <email address hidden>
`. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
`- Use Debian GNU/Linux 3.0! See http://www.debian.org/

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17: "Solution" is not correct

#14

For further studies I built a debug version of qt and tried the "solution"
mentioned in #264928. It does definitely not work. Qt has its own code to
create the exact library name. So the original code QLibrary gl ("GL") is
absolutely correct. Trying the "solution" makes Qt search for a library
called "liblibGL.so.1" as the debug output shows:

(gdb) list
111 };
112
113 bool qt_resolve_gl_symbols(bool fatal)
114 {
115 static bool gl_syms_resolved = FALSE;
116 if (gl_syms_resolved)
117 return TRUE;
118
119 // QLibrary gl ("GL");
120 QLibrary gl ("libGL.so.1");
(gdb) n
120 QLibrary gl ("libGL.so.1");
(gdb)
122 gl.setAutoUnload(FALSE);
(gdb)
124 qt_glCallLists = (_glCallLists) gl.resolve("glCallLists");
(gdb) s
QLibrary::resolve (this=0xbffff910, symb=0x4078552b "glCallLists") at
tools/qlibrary.cpp:227
227 if ( !d->pHnd )
(gdb)
228 load();
(gdb)
QLibrary::load (this=0xbffff910) at tools/qlibrary.cpp:320
320 return d->loadLibrary();
(gdb)
QLibraryPrivate::loadLibrary (this=0x8061cd0) at tools/qlibrary_unix.cpp:109
109 if ( pHnd )
(gdb)
112 QString filename = library->library();
(gdb) n
114 pHnd = dlopen( filename.latin1(), RTLD_LAZY );
(gdb) p filename
$1 = {static null = {static null = <same as static member of an already seen
type>, d = 0x804c108,
static shared_null = 0x804c108}, d = 0x8061e48, static shared_null =
0x804c108}
(gdb) p filename.latin1()
$2 = 0x8061d60 "liblibGL.so.1.so"
(gdb)

I don't know the reason for the problems reported in #264928 but changing the
Qt strategy for finding the OpenGL library causes Qt to malfunction

WR

Revision history for this message

In Debian Bug tracker #266007, Martin Gerhard Loschwitz (martin-loschwitz) wrote on 2004-08-17: Re: Bug#266007: The build process of the debian qt lib seems to have changed

#15

Download full text (5.5 KiB)

On Tue, Aug 17, 2004 at 10:33:44AM +0200, Wolfgang Roemer wrote:
> Some further investigations:
>
> The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built
> with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the
> dependency
> libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
> libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
> libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
> libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
> libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
> libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
> libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
> libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
> libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
> libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
> libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
> libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
> libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
> libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
> libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
> Use ldd on the new qt library (libqt3c102-mt, 3.3.3-2) you get:
> libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
> libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
> libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
> libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
> libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
> libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
> libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
> libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
> libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
> libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
> libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
> libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a3f000)
> libc.so.6 => /lib/tls/libc.so.6 (0x40a48000)
> ...

On Tue, Aug 17, 2004 at 10:33:44AM +0200, Wolfgang Roemer wrote:
> Some further investigations:
> 
> The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built 
> with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the 
> dependency
>         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
>         libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
>         libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
>         libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
>         libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
>         libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
>         libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
>         libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
>         libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
>         libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
>         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
>         libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
>         libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
>         libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
>         libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
>         libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
>         libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
>         libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> 
> Use ldd on the new qt library  (libqt3c102-mt, 3.3.3-2) you get:
>         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
>         libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
>         libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
>         libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
>         libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
>         libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
>         libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
>         libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
>         libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
>         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
>         libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
>         libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
>         libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
>         libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
>         libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
>         libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
>         libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a3f000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x40a48000)
>         libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40b84000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
> 
> You'll notice that there is no "explicit" OpenGL dependency. The interesting 
> file where the decision is made during compile time is 
> 
>  qgl_x11_p.h
> 
> There QT_DLOPEN_OPENGL is used to decide whether the dynamic usage of OpenGL 
> should be chosen (resulting in QLibraryPrivate::loadLibrary (...) and so on) 
> or whether Qt is directly linked to the OpenGL library and 
> qt_resolve_gl_symbols (...) becomes an inline function always returning true.

> The old qt version provided used the second approach as the ldd output I 
> posted indicates. The new version provided seems to have been built with the 
> first approach resulting in problems concerning different OpenGL libraries 
> always present on a system.
> 
> After all I still did not get a clue what exactly is going wrong because even 
> when I ensure that the OpenGL library Qt will find is the correct one, I 
> still get the error.
> 
> WR

It's quite easy what's going on. Qt3 has been built with -dlopen-opengl in
order to make prelinking Qt applications possible although you use nvidia
drivers (the nvidia files are not compiled with -fPIC).

Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the folks
having to use the nvidia drivers (to which I belong myself). The nvidia POS
installs a compability symlink

<0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
lrwxrwxrwx  1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 -> libGL.so.1.0.6111

so that GL should work even if you open libGL.so.1. For me, it does and the
program you used to "reproduce" the bug results in:

<127>madkiss@minerva[1007]:~$ ./bug 
Qt: Locales not supported on X server
Yout system has OpenGL support.

By the way, your compile line for the test-program is wrong as well, it should
say like the following:

g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt

I think the problem rather is in your local setup than in the way Qt handles
OpenGL now. If you are using proprietary drivers from a vendor which do not
even try to comply with official standards, then this is your vendor's or --
unfortunately -- your problem.

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17:

#16

Hello Martin,

On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
...

> It's quite easy what's going on. Qt3 has been built with -dlopen-opengl in
> order to make prelinking Qt applications possible although you use nvidia
> drivers (the nvidia files are not compiled with -fPIC).
>
> Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> folks having to use the nvidia drivers (to which I belong myself). The
> nvidia POS installs a compability symlink
>
> <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> lrwxrwxrwx 1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> libGL.so.1.0.6111

Same for me

>
> so that GL should work even if you open libGL.so.1. For me, it does and the
> program you used to "reproduce" the bug results in:
>
> <127>madkiss@minerva[1007]:~$ ./bug
> Qt: Locales not supported on X server
> Yout system has OpenGL support.
>
> By the way, your compile line for the test-program is wrong as well, it
> should say like the following:
>
> g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt

That's what I did to. I just demonstrated two different link options that have
different results.

Did you read my other post concerning the debug output?
The point is that the current qt library can not find a OpenGL library because
it searches for "liblibGL.so.1.so". It would be interesting to know which
OpenGL library is used during your run of the small test application
demonstrating the bug. One possible reason is of course that in fact another
qt library is used in your setup to test the small application and that this
qt library is one that still uses the old correct approach with QLibrary gl
("GL") instead of QLibrary gl ("libGL.so.1");

WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#17

Download full text (4.2 KiB)

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 10:33:44 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>
Subject: The build process of the debian qt lib seems to have changed

Some further investigations:

The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built
with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the
dependency
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
        libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
        libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Use ldd on the new qt library (libqt3c102-mt, 3.3.3-2) you get:
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
        libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1...

Message-Id: <200408171033.44880.wolfgang.roemer@gmx.net>
Date: Tue, 17 Aug 2004 10:33:44 +0200
From: Wolfgang Roemer <wolfgang.roemer@gmx.net>
To: 266007@bugs.debian.org
Subject: The build process of the debian qt lib seems to have changed

Some further investigations:

The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was built 
with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the 
dependency
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x406e1000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x40709000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4071e000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4076f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40793000)
        libGL.so.1 => /usr/lib/tls/libGL.so.1 (0x407a4000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40801000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40818000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x40824000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x4082d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4083f000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x408ac000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x408bb000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40982000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4098b000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x409a2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x409a5000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x409b4000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a6f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a92000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a9b000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40bd6000)
        libGLcore.so.1 => /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Use ldd on the new qt library  (libqt3c102-mt, 3.3.3-2) you get:
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40702000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x4072a000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4073f000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40790000)
        libz.so.1 => /usr/lib/libz.so.1 (0x407b4000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x407c5000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x407d1000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x407db000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407ed000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4085a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40868000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4092f000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40938000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40950000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40953000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40962000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40a1c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40a3f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40a48000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x40b84000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

You'll notice that there is no "explicit" OpenGL dependency. The interesting 
file where the decision is made during compile time is

qgl_x11_p.h

There QT_DLOPEN_OPENGL is used to decide whether the dynamic usage of OpenGL 
should be chosen (resulting in QLibraryPrivate::loadLibrary (...) and so on) 
or whether Qt is directly linked to the OpenGL library and 
qt_resolve_gl_symbols (...) becomes an inline function always returning true. 
The old qt version provided used the second approach as the ldd output I 
posted indicates. The new version provided seems to have been built with the 
first approach resulting in problems concerning different OpenGL libraries 
always present on a system.

After all I still did not get a clue what exactly is going wrong because even 
when I ensure that the OpenGL library Qt will find is the correct one, I 
still get the error.

WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#18

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 10:47:05 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>
Subject: Trivial compile test

Bytheway: Here is a simple program that is usable to test the qt behaviour:

// Standard C/C++
#include <stdio.h>

// Standard Qt
#include <qapplication.h>
#include <qgl.h>

int main (int argc, char* argv[])
{
QApplication a(argc,argv);

    if (QGLFormat::hasOpenGL() == false)
    {
      qWarning ("This system has no OpenGL support. Exiting.");
      return -1;
    }

printf ("Yout system has OpenGL support.\n");
return 0;
}

There is an interesting point during the linking as well: Normally, because as
I mentioned in my previous post the Qt library will dynamically search for
the OpenGL lib, there is no need to link against OpenGL:

g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt

This command succeeds as expected but crashes during runtime:

~/tests/debian_qt_bug> ./bug
Floating point exception

Linking against the OpenGL library explicitly creates an executable showing
the standard buggy behaviour:

g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt -lGL

~/tests/debian_qt_bug> ./bug
This system has no OpenGL support. Exiting.

WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#19

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 11:26:13 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>,
<email address hidden>
Subject: "Solution" is not correct

For further studies I built a debug version of qt and tried the "solution"
mentioned in #264928. It does definitely not work. Qt has its own code to
create the exact library name. So the original code QLibrary gl ("GL") is
absolutely correct. Trying the "solution" makes Qt search for a library
called "liblibGL.so.1" as the debug output shows:

(gdb) list
111 };
112
113 bool qt_resolve_gl_symbols(bool fatal)
114 {
115 static bool gl_syms_resolved = FALSE;
116 if (gl_syms_resolved)
117 return TRUE;
118
119 // QLibrary gl ("GL");
120 QLibrary gl ("libGL.so.1");
(gdb) n
120 QLibrary gl ("libGL.so.1");
(gdb)
122 gl.setAutoUnload(FALSE);
(gdb)
124 qt_glCallLists = (_glCallLists) gl.resolve("glCallLists");
(gdb) s
QLibrary::resolve (this=0xbffff910, symb=0x4078552b "glCallLists") at
tools/qlibrary.cpp:227
227 if ( !d->pHnd )
(gdb)
228 load();
(gdb)
QLibrary::load (this=0xbffff910) at tools/qlibrary.cpp:320
320 return d->loadLibrary();
(gdb)
QLibraryPrivate::loadLibrary (this=0x8061cd0) at tools/qlibrary_unix.cpp:109
109 if ( pHnd )
(gdb)
112 QString filename = library->library();
(gdb) n
114 pHnd = dlopen( filename.latin1(), RTLD_LAZY );
(gdb) p filename
$1 = {static null = {static null = <same as static member of an already seen
type>, d = 0x804c108,
static shared_null = 0x804c108}, d = 0x8061e48, static shared_null =
0x804c108}
(gdb) p filename.latin1()
$2 = 0x8061d60 "liblibGL.so.1.so"
(gdb)

I don't know the reason for the problems reported in #264928 but changing the
Qt strategy for finding the OpenGL library causes Qt to malfunction

WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#20

Message-ID: <email address hidden>
Date: Tue, 17 Aug 2004 11:23:17 +0200
From: Martin Loschwitz <email address hidden>
To: <email address hidden>
Subject: Downgrading 266007 -- WHAT THE FUCK?!

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

severity 266007 important
thanks

--=20
.''`. Martin Loschwitz Debian GNU/Linux developer
: :' : <email address hidden> <email address hidden>
`. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
`- Use Debian GNU/Linux 3.0! See http://www.debian.org/

--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBIc6FHPo+jNcUXjARAte3AKCxpOSRhq8BSM2Az02Kve77JpLaHwCfZFNE
v6ha/e5LqpkTpORv3QSiAHE=
=aLjV
-----END PGP SIGNATURE-----

--mYCpIKhGyMATD0i+--

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#21

Download full text (6.5 KiB)

Message-ID: <email address hidden>
Date: Tue, 17 Aug 2004 11:31:44 +0200
From: Martin Loschwitz <email address hidden>
To: Wolfgang Roemer <email address hidden>, <email address hidden>
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 17, 2004 at 10:33:44AM +0200, Wolfgang Roemer wrote:
> Some further investigations:
>=20
> The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was =
built=20
> with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the=20
> dependency
> libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x406e1000)
> libaudio.so.2 =3D> /usr/lib/libaudio.so.2 (0x40709000)
> libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x4071e000)
> libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x4076f000)
> libz.so.1 =3D> /usr/lib/libz.so.1 (0x40793000)
> libGL.so.1 =3D> /usr/lib/tls/libGL.so.1 (0x407a4000)
> libXmu.so.6 =3D> /usr/X11R6/lib/libXmu.so.6 (0x40801000)
> libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x40818000)
> libXrandr.so.2 =3D> /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
> libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x40824000)
> libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x4082d000)
> libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x4083f000)
> libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x408ac000)
> libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x408bb000)
> libSM.so.6 =3D> /usr/X11R6/lib/libSM.so.6 (0x40982000)
> libICE.so.6 =3D> /usr/X11R6/lib/libICE.so.6 (0x4098b000)
> libdl.so.2 =3D> /lib/tls/libdl.so.2 (0x409a2000)
> libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x409a5000)
> libstdc++.so.5 =3D> /usr/lib/libstdc++.so.5 (0x409b4000)
> libm.so.6 =3D> /lib/tls/libm.so.6 (0x40a6f000)
> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40a92000)
> libc.so.6 =3D> /lib/tls/libc.so.6 (0x40a9b000)
> libexpat.so.1 =3D> /usr/lib/libexpat.so.1 (0x40bd6000)
> libGLcore.so.1 =3D> /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
> /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
>=20
> Use ldd on the new qt library (libqt3c102-mt, 3.3.3-2) you get:
> libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x40702000)
> libaudio.so.2 =3D> /usr/lib/libaudio.so.2 (0x4072a000)
> libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x4073f000)
> libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x40790000)
> libz.so.1 =3D> /usr/lib/libz.so.1 (0x407b4000)
> libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x407c5000)
> libXrandr.so.2 =3D> /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
> libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x407d1000)
> libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x407db000)
> libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x407ed000)
> libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x4085a000)
> libX11.so.6 =3D> /usr/X11R6/lib/libX...

Message-ID: <20040817093144.GB4611@minerva.local.lan>
Date: Tue, 17 Aug 2004 11:31:44 +0200
From: Martin Loschwitz <madkiss@debian.org>
To: Wolfgang Roemer <wolfgang.roemer@gmx.net>, 266007@bugs.debian.org
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 17, 2004 at 10:33:44AM +0200, Wolfgang Roemer wrote:
> Some further investigations:
>=20
> The last version of the provided qt library (libqt3c102-mt, 3.2.3-4) was =
built=20
> with "explicit" OpenGL support: An ldd on libqt-mt.so.3.2.3 shows the=20
> dependency
>         libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x406e1000)
>         libaudio.so.2 =3D> /usr/lib/libaudio.so.2 (0x40709000)
>         libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x4071e000)
>         libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x4076f000)
>         libz.so.1 =3D> /usr/lib/libz.so.1 (0x40793000)
>         libGL.so.1 =3D> /usr/lib/tls/libGL.so.1 (0x407a4000)
>         libXmu.so.6 =3D> /usr/X11R6/lib/libXmu.so.6 (0x40801000)
>         libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x40818000)
>         libXrandr.so.2 =3D> /usr/X11R6/lib/libXrandr.so.2 (0x40820000)
>         libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x40824000)
>         libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x4082d000)
>         libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x4083f000)
>         libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x408ac000)
>         libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x408bb000)
>         libSM.so.6 =3D> /usr/X11R6/lib/libSM.so.6 (0x40982000)
>         libICE.so.6 =3D> /usr/X11R6/lib/libICE.so.6 (0x4098b000)
>         libdl.so.2 =3D> /lib/tls/libdl.so.2 (0x409a2000)
>         libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x409a5000)
>         libstdc++.so.5 =3D> /usr/lib/libstdc++.so.5 (0x409b4000)
>         libm.so.6 =3D> /lib/tls/libm.so.6 (0x40a6f000)
>         libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40a92000)
>         libc.so.6 =3D> /lib/tls/libc.so.6 (0x40a9b000)
>         libexpat.so.1 =3D> /usr/lib/libexpat.so.1 (0x40bd6000)
>         libGLcore.so.1 =3D> /usr/lib/tls/libGLcore.so.1 (0x40bf6000)
>         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
>=20
> Use ldd on the new qt library  (libqt3c102-mt, 3.3.3-2) you get:
>         libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x40702000)
>         libaudio.so.2 =3D> /usr/lib/libaudio.so.2 (0x4072a000)
>         libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x4073f000)
>         libpng12.so.0 =3D> /usr/lib/libpng12.so.0 (0x40790000)
>         libz.so.1 =3D> /usr/lib/libz.so.1 (0x407b4000)
>         libXrender.so.1 =3D> /usr/lib/libXrender.so.1 (0x407c5000)
>         libXrandr.so.2 =3D> /usr/X11R6/lib/libXrandr.so.2 (0x407cd000)
>         libXcursor.so.1 =3D> /usr/lib/libXcursor.so.1 (0x407d1000)
>         libXft.so.2 =3D> /usr/lib/libXft.so.2 (0x407db000)
>         libfreetype.so.6 =3D> /usr/lib/libfreetype.so.6 (0x407ed000)
>         libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x4085a000)
>         libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x40868000)
>         libSM.so.6 =3D> /usr/X11R6/lib/libSM.so.6 (0x4092f000)
>         libICE.so.6 =3D> /usr/X11R6/lib/libICE.so.6 (0x40938000)
>         libdl.so.2 =3D> /lib/tls/libdl.so.2 (0x40950000)
>         libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x40953000)
>         libstdc++.so.5 =3D> /usr/lib/libstdc++.so.5 (0x40962000)
>         libm.so.6 =3D> /lib/tls/libm.so.6 (0x40a1c000)
>         libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40a3f000)
>         libc.so.6 =3D> /lib/tls/libc.so.6 (0x40a48000)
>         libexpat.so.1 =3D> /usr/lib/libexpat.so.1 (0x40b84000)
>         /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
>=20
> You'll notice that there is no "explicit" OpenGL dependency. The interest=
ing=20
> file where the decision is made during compile time is=20
>=20
>  qgl_x11_p.h
>=20
> There QT_DLOPEN_OPENGL is used to decide whether the dynamic usage of Ope=
nGL=20
> should be chosen (resulting in QLibraryPrivate::loadLibrary (...) and so =
on)=20
> or whether Qt is directly linked to the OpenGL library and=20
> qt_resolve_gl_symbols (...) becomes an inline function always returning t=
rue.=20

> The old qt version provided used the second approach as the ldd output I=
=20
> posted indicates. The new version provided seems to have been built with =
the=20
> first approach resulting in problems concerning different OpenGL librarie=
s=20
> always present on a system.
>=20
> After all I still did not get a clue what exactly is going wrong because =
even=20
> when I ensure that the OpenGL library Qt will find is the correct one, I=
=20
> still get the error.
>=20
> WR

It's quite easy what's going on. Qt3 has been built with -dlopen-opengl in
order to make prelinking Qt applications possible although you use nvidia
drivers (the nvidia files are not compiled with -fPIC).=20

Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the folks
having to use the nvidia drivers (to which I belong myself). The nvidia POS
installs a compability symlink=20

<0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
lrwxrwxrwx  1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 -> libGL.so=
=2E1.0.6111

so that GL should work even if you open libGL.so.1. For me, it does and the
program you used to "reproduce" the bug results in:

<127>madkiss@minerva[1007]:~$ ./bug=20
Qt: Locales not supported on X server
Yout system has OpenGL support.

By the way, your compile line for the test-program is wrong as well, it sho=
uld
say like the following:

g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt

I think the problem rather is in your local setup than in the way Qt handles
OpenGL now. If you are using proprietary drivers from a vendor which do not
even try to comply with official standards, then this is your vendor's or --
unfortunately -- your problem.=20

--=20
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

--7ZAtKRhVyVSsbBD2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBIdCAHPo+jNcUXjARAsHgAKC4Bc4eLVjOGlERy5VCu+5lTKVdVACgin42
0W2qxNzwC5/jaY5otVoXt6I=
=6hpl
-----END PGP SIGNATURE-----

--7ZAtKRhVyVSsbBD2--

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#22

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 12:09:18 +0200
From: Wolfgang Roemer <email address hidden>
To: Martin Loschwitz <email address hidden>,
<email address hidden>
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

Hello Martin,

On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
...

> It's quite easy what's going on. Qt3 has been built with -dlopen-opengl in
> order to make prelinking Qt applications possible although you use nvidia
> drivers (the nvidia files are not compiled with -fPIC).
>
> Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> folks having to use the nvidia drivers (to which I belong myself). The
> nvidia POS installs a compability symlink
>
> <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> lrwxrwxrwx 1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> libGL.so.1.0.6111

Same for me

>
> so that GL should work even if you open libGL.so.1. For me, it does and the
> program you used to "reproduce" the bug results in:
>
> <127>madkiss@minerva[1007]:~$ ./bug
> Qt: Locales not supported on X server
> Yout system has OpenGL support.
>
> By the way, your compile line for the test-program is wrong as well, it
> should say like the following:
>
> g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt

That's what I did to. I just demonstrated two different link options that have
different results.

Did you read my other post concerning the debug output?
The point is that the current qt library can not find a OpenGL library because
it searches for "liblibGL.so.1.so". It would be interesting to know which
OpenGL library is used during your run of the small test application
demonstrating the bug. One possible reason is of course that in fact another
qt library is used in your setup to test the small application and that this
qt library is one that still uses the old correct approach with QLibrary gl
("GL") instead of QLibrary gl ("libGL.so.1");

WR

Message-Id: <200408171209.18899.wolfgang.roemer@gmx.net>
Date: Tue, 17 Aug 2004 12:09:18 +0200
From: Wolfgang Roemer <wolfgang.roemer@gmx.net>
To: Martin Loschwitz <madkiss@debian.org>,
 266007@bugs.debian.org
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

Hello Martin,

On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
...

> It's quite easy what's going on. Qt3 has been built with -dlopen-opengl in
> order to make prelinking Qt applications possible although you use nvidia
> drivers (the nvidia files are not compiled with -fPIC).
>
> Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> folks having to use the nvidia drivers (to which I belong myself). The
> nvidia POS installs a compability symlink
>
> <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> lrwxrwxrwx  1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> libGL.so.1.0.6111

Same for me

>
> so that GL should work even if you open libGL.so.1. For me, it does and the
> program you used to "reproduce" the bug results in:
>
> <127>madkiss@minerva[1007]:~$ ./bug
> Qt: Locales not supported on X server
> Yout system has OpenGL support.
>
> By the way, your compile line for the test-program is wrong as well, it
> should say like the following:
>
> g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt

That's what I did to. I just demonstrated two different link options that have 
different results.

Did you read my other post concerning the debug output?
The point is that the current qt library can not find a OpenGL library because 
it searches for "liblibGL.so.1.so". It would be interesting to know which 
OpenGL library is used during your run of the small test application 
demonstrating the bug. One possible reason is of course that in fact another 
qt library is used in your setup to test the small application and that this 
qt library is one that still uses the old correct approach with QLibrary gl 
("GL") instead of QLibrary gl ("libGL.so.1");

WR

Revision history for this message

In Debian Bug tracker #266007, Pierre Habouzit (madcoder) wrote on 2004-08-17: No problem here ...

#23

using qt 3.3.3-2, up to date KDE

I've launched /usr/bin/ksolarwinds.kss, /usr/bin/keuphoria.kss with no
problem at all. with proprietary nvidia (6111) as well

so I think you should upgrade your system cleanly
--
Pierre Habouzit http://www.madism.org/
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE
spam: <email address hidden>

Revision history for this message

In Debian Bug tracker #266007, =?iso-8859-15?q?K=E9vin_Ottens?= (ervin-ipsquad) wrote on 2004-08-17: It works here

#24

Hello,

Please note that OpenGL applications using Qt work here, in particular the KDE
screensavers. My current packages version for Qt is 3.3.3-1.

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17: Re: Bug#266007: It works here

#25

Hello,

do you use the proprietary nvidia driver?

WR

On Tuesday 17 August 2004 14:39, Kévin Ottens wrote:
> Hello,
>
> Please note that OpenGL applications using Qt work here, in particular the
> KDE screensavers. My current packages version for Qt is 3.3.3-1.
>
> Regards.

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (wolfgang-roemer) wrote on 2004-08-17: Re: Bug#266007: The build process of the debian qt lib seems to have changed

#26

Download full text (3.2 KiB)

Hello Martin,

you never mentioned it but the way the qt library was changed in qgl_x11.cpp
is actually

QLibrary gl("/usr/lib/libGL.so.1")

and not the way I thought it was changed

QLibrary gl ("libGL.so.1")

(I realized that when I had a look at the qt-x11-free_3.3.3-2.diff.gz file).
So to summarize it: The way the qt library was changed should work well
because if there is an absolut path given to QLibrary, qt does not
extend/change the given name and therefor qt really tries to
dlopen /usr/lib/libGL.so.1

Now for me the question is why this call seems to don't succeed on my
system.... I will do some further investigation on my machine.

WR

On Tuesday 17 August 2004 12:29, you wrote:
> On Tue, Aug 17, 2004 at 12:09:18PM +0200, Wolfgang Roemer wrote:
> > Hello Martin,
> >
> > On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
> > ...
> >
> > > It's quite easy what's going on. Qt3 has been built with -dlopen-opengl
> > > in order to make prelinking Qt applications possible although you use
> > > nvidia drivers (the nvidia files are not compiled with -fPIC).
> > >
> > > Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> > > folks having to use the nvidia drivers (to which I belong myself). The
> > > nvidia POS installs a compability symlink
> > >
> > > <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> > > lrwxrwxrwx 1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> > > libGL.so.1.0.6111
> >
> > Same for me
>
> Then there should be no problem.
>
> > > so that GL should work even if you open libGL.so.1. For me, it does and
> > > the program you used to "reproduce" the bug results in:
> > >
> > > <127>madkiss@minerva[1007]:~$ ./bug
> > > Qt: Locales not supported on X server
> > > Yout system has OpenGL support.
> > >
> > > By the way, your compile line for the test-program is wrong as well, it
> > > should say like the following:
> > >
> > > g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt
> >
> > That's what I did to. I just demonstrated two different link options that
> > have different results.
>
> No, you used "g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt" and that's
> obviously different.
>
> > Did you read my other post concerning the debug output?
> >
> > The point is that the current qt library can not find a OpenGL library
> > because it searches for "liblibGL.so.1.so". It would be interesting to
> > know which OpenGL library is used during your run of the small test
> > application demonstrating the bug. One possible reason is of course that
> > in fact another qt library is used in your setup to test the small
> > application and that this qt library is one that still uses the old
> > correct approach with QLibrary gl ("GL") instead of QLibrary gl
> > ("libGL.so.1");
>
> Thank you for thinking of me as a dumb person; no, I am infact testing with
> the Qt in the archive and no other library.
>
> Now, to make it clear even for you: THE OLD APPROACH IS NOT CORRECT BECAUSE
> IT SEARCHES FOR libGL.so WHICH IS ONLY IN THE -DEV-PACKAGES AND THUS SIMPLY
> NOT THERE ON MOST USERS' SYSTEMS. If the old approach with "GL" does not
> work as we want it (and it doesn't, obviously) and if even the n...

Hello Martin,

you never mentioned it but the way the qt library was changed in qgl_x11.cpp 
is actually

QLibrary gl("/usr/lib/libGL.so.1")

and not the way I thought it was changed

QLibrary gl ("libGL.so.1")

(I realized that when I had a look at the qt-x11-free_3.3.3-2.diff.gz file). 
So to summarize it: The way the qt library was changed should work well 
because if there is an absolut path given to QLibrary, qt does not 
extend/change the given name and therefor qt really tries to 
dlopen /usr/lib/libGL.so.1

Now for me the question is why this call seems to don't succeed on my 
system.... I will do some further investigation on my machine.

WR

On Tuesday 17 August 2004 12:29, you wrote:
> On Tue, Aug 17, 2004 at 12:09:18PM +0200, Wolfgang Roemer wrote:
> > Hello Martin,
> >
> > On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
> > ...
> >
> > > It's quite easy what's going on. Qt3 has been built with -dlopen-opengl
> > > in order to make prelinking Qt applications possible although you use
> > > nvidia drivers (the nvidia files are not compiled with -fPIC).
> > >
> > > Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> > > folks having to use the nvidia drivers (to which I belong myself). The
> > > nvidia POS installs a compability symlink
> > >
> > > <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> > > lrwxrwxrwx  1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> > > libGL.so.1.0.6111
> >
> > Same for me
>
> Then there should be no problem.
>
> > > so that GL should work even if you open libGL.so.1. For me, it does and
> > > the program you used to "reproduce" the bug results in:
> > >
> > > <127>madkiss@minerva[1007]:~$ ./bug
> > > Qt: Locales not supported on X server
> > > Yout system has OpenGL support.
> > >
> > > By the way, your compile line for the test-program is wrong as well, it
> > > should say like the following:
> > >
> > > g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt
> >
> > That's what I did to. I just demonstrated two different link options that
> > have different results.
>
> No, you used "g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt" and that's
> obviously different.
>
> > Did you read my other post concerning the debug output?
> >
> > The point is that the current qt library can not find a OpenGL library
> > because it searches for "liblibGL.so.1.so". It would be interesting to
> > know which OpenGL library is used during your run of the small test
> > application demonstrating the bug. One possible reason is of course that
> > in fact another qt library is used in your setup to test the small
> > application and that this qt library is one that still uses the old
> > correct approach with QLibrary gl ("GL") instead of QLibrary gl
> > ("libGL.so.1");
>
> Thank you for thinking of me as a dumb person; no, I am infact testing with
> the Qt in the archive and no other library.
>
> Now, to make it clear even for you: THE OLD APPROACH IS NOT CORRECT BECAUSE
> IT SEARCHES FOR libGL.so WHICH IS ONLY IN THE -DEV-PACKAGES AND THUS SIMPLY
> NOT THERE ON MOST USERS' SYSTEMS. If the old approach with "GL" does not
> work as we want it (and it doesn't, obviously) and if even the new approach
> does not work, we need to hack on the QLibrary functions.
>
> > WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#27

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 14:33:56 +0200
From: Pierre Habouzit <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: No problem here ...

--nextPart1770179.HpkOBLZIAB
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

using qt 3.3.3-2, up to date KDE

I've launched /usr/bin/ksolarwinds.kss, /usr/bin/keuphoria.kss with no=20
problem at all. with proprietary nvidia (6111) as well

so I think you should upgrade your system cleanly
=2D-=20
Pierre Habouzit http://www.madism.org/
=2D=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=
=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D-
gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE=20
spam: <email address hidden>

--nextPart1770179.HpkOBLZIAB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBBIfs3vGr7W6HudhwRArlVAJ4iK51UgcaDiNPvHmE2gEsOgYr5WQCfcBiy
JEmnrqc2Yp3HhmDxBHBHyf0=
=9+Nn
-----END PGP SIGNATURE-----

--nextPart1770179.HpkOBLZIAB--

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#28

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 14:39:32 +0200
From: =?iso-8859-15?q?K=E9vin_Ottens?= <email address hidden>
To: <email address hidden>
Subject: It works here

Hello,

Please note that OpenGL applications using Qt work here, in particular the =
KDE=20
screensavers. My current packages version for Qt is 3.3.3-1.

Regards.
=2D-=20
K=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
Ne font reculer l'ignorance."

Revision history for this message

In Debian Bug tracker #266007, =?iso-8859-15?q?K=E9vin_Ottens?= (ervin-ipsquad) wrote on 2004-08-17: Re: Bug#266007: It works here

#29

Le mardi 17 Août 2004 15:57, Wolfgang Roemer a écrit :
> do you use the proprietary nvidia driver?

Sorry, I forgot the most important point... Yes, I use it, that's why I
replied in the first place. ;-)

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#30

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 15:57:10 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>,
<email address hidden>
Subject: Re: Bug#266007: It works here

Hello,

do you use the proprietary nvidia driver?

WR

On Tuesday 17 August 2004 14:39, K=E9vin Ottens wrote:
> Hello,
>
> Please note that OpenGL applications using Qt work here, in particular the
> KDE screensavers. My current packages version for Qt is 3.3.3-1.
>
> Regards.

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#31

Download full text (3.5 KiB)

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 16:05:05 +0200
From: Wolfgang Roemer <email address hidden>
To: Martin Loschwitz <email address hidden>,
<email address hidden>
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

Hello Martin,

you never mentioned it but the way the qt library was changed in qgl_x11.cpp
is actually

QLibrary gl("/usr/lib/libGL.so.1")

and not the way I thought it was changed

QLibrary gl ("libGL.so.1")

(I realized that when I had a look at the qt-x11-free_3.3.3-2.diff.gz file).
So to summarize it: The way the qt library was changed should work well
because if there is an absolut path given to QLibrary, qt does not
extend/change the given name and therefor qt really tries to
dlopen /usr/lib/libGL.so.1

Now for me the question is why this call seems to don't succeed on my
system.... I will do some further investigation on my machine.

WR

On Tuesday 17 August 2004 12:29, you wrote:
> On Tue, Aug 17, 2004 at 12:09:18PM +0200, Wolfgang Roemer wrote:
> > Hello Martin,
> >
> > On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
> > ...
> >
> > > It's quite easy what's going on. Qt3 has been built with -dlopen-opengl
> > > in order to make prelinking Qt applications possible although you use
> > > nvidia drivers (the nvidia files are not compiled with -fPIC).
> > >
> > > Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> > > folks having to use the nvidia drivers (to which I belong myself). The
> > > nvidia POS installs a compability symlink
> > >
> > > <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> > > lrwxrwxrwx 1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> > > libGL.so.1.0.6111
> >
> > Same for me
>
> Then there should be no problem.
>
> > > so that GL should work even if you open libGL.so.1. For me, it does and
> > > the program you used to "reproduce" the bug results in:
> > >
> > > <127>madkiss@minerva[1007]:~$ ./bug
> > > Qt: Locales not supported on X server
> > > Yout system has OpenGL support.
> > >
> > > By the way, your compile line for the test-program is wrong as well, it
> > > should say like the following:
> > >
> > > g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt
> >
> > That's what I did to. I just demonstrated two different link options that
> > have different results.
>
> No, you used "g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt" and that's
> obviously different.
>
> > Did you read my other post concerning the debug output?
> >
> > The point is that the current qt library can not find a OpenGL library
> > because it searches for "liblibGL.so.1.so". It would be interesting to
> > know which OpenGL library is used during your run of the small test
> > application demonstrating the bug. One possible reason is of course that
> > in fact another qt library is used in your setup to test the small
> > application and that this qt library is one that still uses the old
> > correct approach with QLibrary gl ("GL") instead of QLibrary gl
> > ("libGL.so.1");
>
> Thank you for thinking of me as a dumb person; no, I am infact testing with
> the Qt in the archive and no other library.
>
...

Message-Id: <200408171605.05640.wolfgang.roemer@gmx.net>
Date: Tue, 17 Aug 2004 16:05:05 +0200
From: Wolfgang Roemer <wolfgang.roemer@gmx.net>
To: Martin Loschwitz <madkiss@debian.org>,
 266007@bugs.debian.org
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

Hello Martin,

you never mentioned it but the way the qt library was changed in qgl_x11.cpp 
is actually

QLibrary gl("/usr/lib/libGL.so.1")

and not the way I thought it was changed

QLibrary gl ("libGL.so.1")

(I realized that when I had a look at the qt-x11-free_3.3.3-2.diff.gz file). 
So to summarize it: The way the qt library was changed should work well 
because if there is an absolut path given to QLibrary, qt does not 
extend/change the given name and therefor qt really tries to 
dlopen /usr/lib/libGL.so.1

Now for me the question is why this call seems to don't succeed on my 
system.... I will do some further investigation on my machine.

WR

On Tuesday 17 August 2004 12:29, you wrote:
> On Tue, Aug 17, 2004 at 12:09:18PM +0200, Wolfgang Roemer wrote:
> > Hello Martin,
> >
> > On Tuesday 17 August 2004 11:31, Martin Loschwitz wrote:
> > ...
> >
> > > It's quite easy what's going on. Qt3 has been built with -dlopen-opengl
> > > in order to make prelinking Qt applications possible although you use
> > > nvidia drivers (the nvidia files are not compiled with -fPIC).
> > >
> > > Hard-linking Qt to libGL.so.1 ought to be no problem, even not for the
> > > folks having to use the nvidia drivers (to which I belong myself). The
> > > nvidia POS installs a compability symlink
> > >
> > > <0>madkiss@minerva[1001]:~$ ls -lah /usr/lib/libGL.so.1
> > > lrwxrwxrwx  1 root root 17 2004-08-14 12:34 /usr/lib/libGL.so.1 ->
> > > libGL.so.1.0.6111
> >
> > Same for me
>
> Then there should be no problem.
>
> > > so that GL should work even if you open libGL.so.1. For me, it does and
> > > the program you used to "reproduce" the bug results in:
> > >
> > > <127>madkiss@minerva[1007]:~$ ./bug
> > > Qt: Locales not supported on X server
> > > Yout system has OpenGL support.
> > >
> > > By the way, your compile line for the test-program is wrong as well, it
> > > should say like the following:
> > >
> > > g++ -o bug bug.cpp -I/usr/include/qt3 -lqt-mt
> >
> > That's what I did to. I just demonstrated two different link options that
> > have different results.
>
> No, you used "g++ -o bug bug.cpp -I/usr/include/qt -lqt-mt" and that's
> obviously different.
>
> > Did you read my other post concerning the debug output?
> >
> > The point is that the current qt library can not find a OpenGL library
> > because it searches for "liblibGL.so.1.so". It would be interesting to
> > know which OpenGL library is used during your run of the small test
> > application demonstrating the bug. One possible reason is of course that
> > in fact another qt library is used in your setup to test the small
> > application and that this qt library is one that still uses the old
> > correct approach with QLibrary gl ("GL") instead of QLibrary gl
> > ("libGL.so.1");
>
> Thank you for thinking of me as a dumb person; no, I am infact testing with
> the Qt in the archive and no other library.
>
> Now, to make it clear even for you: THE OLD APPROACH IS NOT CORRECT BECAUSE
> IT SEARCHES FOR libGL.so WHICH IS ONLY IN THE -DEV-PACKAGES AND THUS SIMPLY
> NOT THERE ON MOST USERS' SYSTEMS. If the old approach with "GL" does not
> work as we want it (and it doesn't, obviously) and if even the new approach
> does not work, we need to hack on the QLibrary functions.
>
> > WR

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#32

Message-Id: <email address hidden>
Date: Tue, 17 Aug 2004 16:34:02 +0200
From: =?iso-8859-15?q?K=E9vin_Ottens?= <email address hidden>
To: Wolfgang Roemer <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#266007: It works here

Le mardi 17 Ao=FBt 2004 15:57, Wolfgang Roemer a =E9crit :
> do you use the proprietary nvidia driver?

Sorry, I forgot the most important point... Yes, I use it, that's why I=20
replied in the first place. ;-)

Regards.
=2D-=20
K=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
Ne font reculer l'ignorance."

Revision history for this message

In Debian Bug tracker #266007, Martin Gerhard Loschwitz (martin-loschwitz) wrote on 2004-08-17: Re: Bug#266007: The build process of the debian qt lib seems to have changed

#33

Wolfgang,

how did you have the idea I changed it to "libGL.so.1"? I tried that in an
inofficial version but soon noticed that this was not going to work, so I
withdraw that I idea and specified an absolute path. Let me know once you
found the root of your problem.

--
.''`. Martin Loschwitz Debian GNU/Linux developer
: :' : <email address hidden> <email address hidden>
`. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
`- Use Debian GNU/Linux 3.0! See http://www.debian.org/

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-17:

#34

Message-ID: <email address hidden>
Date: Tue, 17 Aug 2004 18:23:15 +0200
From: Martin Loschwitz <email address hidden>
To: <email address hidden>
Subject: Re: Bug#266007: The build process of the debian qt lib seems to have changed

--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Wolfgang,

how did you have the idea I changed it to "libGL.so.1"? I tried that in an
inofficial version but soon noticed that this was not going to work, so I
withdraw that I idea and specified an absolute path. Let me know once you
found the root of your problem.

--=20
.''`. Martin Loschwitz Debian GNU/Linux developer
: :' : <email address hidden> <email address hidden>
`. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
`- Use Debian GNU/Linux 3.0! See http://www.debian.org/

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBIjDzHPo+jNcUXjARAoZYAJ4g+X5ho4r6XIY6dFo3d00vCvxfZQCbBsmz
wnwyCFdOIdTYm71p6ojn+LI=
=U0+0
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--

Revision history for this message

In Debian Bug tracker #266007, Wolfgang Roemer (roemer) wrote on 2004-08-18: Root of problem

#35

Hello Martin,

Ben assumed that #266007 is a duplicate of #264928. There it was mentioned
that the solution is to use "libGL.so.1" instead of "GL" in the call of the
constructor of QLibrary. That's the reason why I built a qt version with that
change. This qt library showed exactly the same effect as my 3:3.3.3-1 system
qt library. Therefore I assumed that this is the way the qt library from
debian was changed. Having a look at the "diff files" showed me that I was
wrong. But nevertheless my system behaved that strange way although it worked
perfectly just before my upgrade to the new KDE and Qt packages from debian.

Sofar I used the nvidia proprietary driver version 5336. The nvidia change
logs for 6111 showed nothing interesting and therefore I did not upgrade to
that version. BUT THE PROBLEM HAS IN FACT TO DO WITH THE NVIDIA DRIVER
VERSION: The drivers available from nvidia work with the new debian qt
version starting with 6106. Older versions showed the strange behaviour that
is the subject of this "bug". I have no clue what is going wrong with the
older driver because the way the libs are named and the way the symbolic
links in the filesystem are made shows no differences to the way the 6111
version does it and as I said before, the 5336 worked without any problems
just before upgrading to the new qt version 3:3.3.3-1.

Thanks for all your help.
--
Wolfgang Römer

Software Engineer
<email address hidden>
Tel. +49-6221-73920-65

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-08-18:

#36

Message-Id: <email address hidden>
Date: Wed, 18 Aug 2004 08:07:40 +0200
From: Wolfgang Roemer <email address hidden>
To: <email address hidden>
Subject: Root of problem

Hello Martin,

Ben assumed that #266007 is a duplicate of #264928. There it was mentioned=
=20
that the solution is to use "libGL.so.1" instead of "GL" in the call of the=
=20
constructor of QLibrary. That's the reason why I built a qt version with th=
at=20
change. This qt library showed exactly the same effect as my 3:3.3.3-1 syst=
em=20
qt library. Therefore I assumed that this is the way the qt library from=20
debian was changed. Having a look at the "diff files" showed me that I was=
=20
wrong. But nevertheless my system behaved that strange way although it work=
ed=20
perfectly just before my upgrade to the new KDE and Qt packages from debian.

Sofar I used the nvidia proprietary driver version 5336. The nvidia change=
=20
logs for 6111 showed nothing interesting and therefore I did not upgrade to=
=20
that version. BUT THE PROBLEM HAS IN FACT TO DO WITH THE NVIDIA DRIVER=20
VERSION: The drivers available from nvidia work with the new debian qt=20
version starting with 6106. Older versions showed the strange behaviour tha=
t=20
is the subject of this "bug". I have no clue what is going wrong with the=20
older driver because the way the libs are named and the way the symbolic=20
links in the filesystem are made shows no differences to the way the 6111=20
version does it and as I said before, the 5336 worked without any problems=
=20
just before upgrading to the new qt version 3:3.3.3-1.

Thanks for all your help.
=2D-=20
Wolfgang R=F6mer

Software Engineer
<email address hidden>
Tel. +49-6221-73920-65

Revision history for this message

Matt Zimmerman (mdz) wrote on 2004-08-26:

#37

Doesn't seem to affect Warty:

mdz@ubuntu /tmp $ DISPLAY=:0.0 ./bug
Yout system has OpenGL support.

Revision history for this message

In Debian Bug tracker #266007, Josh Metzler (joshdeb) wrote on 2004-11-20: upgrading binary nvidia drivers to 6111 fixes this problem

#38

For some reason, the libGL.so.1 that the nvidia driver 5336 installs does
not work for qt. Upgrading to 6111 solves this problem.

Josh

Revision history for this message

Debian Bug Importer (debzilla) wrote on 2004-11-20:

#39

Message-Id: <email address hidden>
Date: Fri, 19 Nov 2004 22:43:38 -0500
From: Josh Metzler <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: upgrading binary nvidia drivers to 6111 fixes this problem

For some reason, the libGL.so.1 that the nvidia driver 5336 installs does
not work for qt. Upgrading to 6111 solves this problem.

Josh

Bug Watch Updater (bug-watch-updater) on 2006-09-27

Changed in qt-x11-free:
status:	Unknown → Fix Released

Affects		Status	Importance	Assigned to	Milestone
	qt-x11-free (Debian)	Fix Released	Unknown	debbugs #266007
	qt-x11-free (Ubuntu)	Invalid	High	Unassigned

Ubuntu
qt-x11-free package

general: "Unable to resolve GL/GLX symbols message when starting OpenGL application"

Bug Description

Other bug subscribers

Remote bug watches

Ubuntuqt-x11-free package

general: "Unable to resolve GL/GLX symbols message when starting OpenGL application"

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
qt-x11-free package