1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#266007: The build process of the debian qt lib seems to have change

    From Wolfgang Roemer@1:229/2 to All on Tue Aug 17 11:00:14 2004
    From: [email protected]

    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



    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Martin Loschwitz@1:229/2 to Wolfgang Roemer on Tue Aug 17 12:00:14 2004
    From: [email protected]

    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
    : :' : [email protected] [email protected]
    `. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
    `- Use Debian GNU/Linux 3.0! See http://www.debian.org/

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


    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Wolfgang Roemer@1:229/2 to Martin Loschwitz on Tue Aug 17 12:30:09 2004
    From: [email protected]

    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


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Wolfgang Roemer@1:229/2 to you on Tue Aug 17 16:30:14 2004
    From: [email protected]

    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


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Martin Loschwitz@1:229/2 to All on Tue Aug 17 18:40:11 2004
    From: [email protected]

    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 protected] [email protected]
    `. `'` http://www.madkiss.org/ people.debian.org/~madkiss/
    `- Use Debian GNU/Linux 3.0! See http://www.debian.org/

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

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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)