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:
../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):
&& /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"
-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
GPG: FEA2 A3FE
More information about the kde-core-devel