possible arts build problem

Julian Rockey linux at jrockey.com
Fri Apr 5 07:51:12 BST 2002


The ARTS build-system problem below (which I posted on kde-devel) also occurs 
with the KDE 3.0 release. I resolved it by moving the unused QT 2.3.1 
libqt-mt library and links from /usr/lib. This may be of interest to others. 
If you're getting a few odd segfaults and you have both QT2 and QT3 installed 
check all your KDE3 libraries with LDD to ensure they're linked against the 
correct QT.

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

Possible problem with the build system:

I've got QT 2 in /usr/lib and QT 3.0.3 in /opt/qt/qt3

I compiled arts, kdelibs and kdebase from KDE3.0RC3 packages (setting QTDIR 
correctly etc.) Checking with ldd, the kdelibs and kdebase libraries are 
fine; however, libqtmcop in the arts package has linked against the old 
QT.

Looking at what's happening: libtool generates a link command along the lines 
of:

g++ <blah blah> -L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/../../.. 
-L/usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96 -L/opt/qt/qt3/lib 
-L/usr/X11R6/lib <blah blah>-o .libs/libqtmcop.so.1.0.0

To my mind, because of that first -L (which effectively reduces to /usr/lib), 
the libqt-mt from QT2 is being picked up first from /usr/lib. If I manaully 
linked, putting -L/opt/qt/qt3/lib before the -L/usr/lib/gcc-lib/..... then 
ldd libqtmcop.so.1.0.0 shows it linked against QT3 correctly.

So-- is this wrong? Should libtool be placing extra libraries *before* the 
'usual' ones?

Of course, I can simply remove /usr/lib/libqt-mt as we don't link against 
multi-threaded QT 2.x but my concern is whether the build system has a 
problem here. /usr/lib/libqt-mt comes installed by default with Mandrake 8.1.

Julian




More information about the kde-core-devel mailing list