rpaths on linux with kde3 installed

Adriaan de Groot groot at kde.org
Tue May 23 22:37:19 BST 2006

I'm trying to build KDE4 SVN trunk (r. 544176) on a Kubuntu system (6.06). I'm 
using home-built CMake 2.4.2 because the packaged CMake on Kubuntu is 2.2. A 
clean build keeps ending up like this:

Generating ksycoca_skel.cpp
../bin/dcopidl2cpp.sh: line 4: 16565 Segmentation fault      
$LD_LIBRARY_PATH} "/tmp/bu/bin/dcopidl2cpp" "$@"

A quick gdb session shows that dcopidl2cpp is crashing inside libqt-mt.so. 
*Where?* you ask? There's nothing that links against libqt-mt.so in KDE4.

Here's the top of the ldd output for the dcopidp2cpp that is being run:

adridg at ham:/tmp/bu$ ldd /tmp/bu/bin/dcopidl2cpp
        linux-gate.so.1 =>  (0xffffe000)
        libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0xb7e66000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e3f000)
        libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0xb7dfc000)
        libDCOP.so.4 => /usr/lib/libDCOP.so.4 (0xb7dcb000)
        libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb736c000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7348000)

Notice, in particular, that libDCOP is being picked up in the standard library 
location -- that is, the installed KDE3 version -- instead of the one from 
the build dir. No amount of futzing with LD_LIBRARY_PATH or LD_RUN_PATH seems 
to make a lick of difference.

Let's go back to the compilation of dcopidl2cpp then. That rounds up with 
(wrapped for clarity):

cd /tmp/bu/dcop/dcopidl2cpp 
&& /usr/bin/c++     -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align 
-Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security 
-fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -O2 -g 
 -fPIC "CMakeFiles/dcopidl2cpp.dir/main.o" "CMakeFiles/dcopidl2cpp.dir/skel.o"
 "CMakeFiles/dcopidl2cpp.dir/stub.o" "CMakeFiles/dcopidl2cpp.dir/stubimpl.o"  
 -o ../../bin/dcopidl2cpp -rdynamic
 -L/usr/local/lib -L/tmp/bu/lib/. -L/tmp/bu/lib 
-lQtCore -lpthread -lQtXml -lDCOP -lQtCore -lpthread -Wl,-rpath,/usr/local/lib:/usr/lib

While the -L's look OK, the -rpath part seems to be dodgy. If I modify the 
build command to use


then the right library -- from the build dir -- *is* picked up. But this 
doesn't seem like a good solution, since it embeds a build dir into the 
executable which might not be around (or might be hi-jacked) later. How to 
work around this?

KDE Quality Team

More information about the kde-core-devel mailing list