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/lib/./:/usr/local/lib:/tmp/bu/lib/.:/usr/lib${LD_LIBRARY_PATH+: $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: [EMAIL PROTECTED]:/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 -Wl,-rpath,/tmp/bu/lib:/usr/local/lib:/usr/lib 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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem