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