rpaths on linux with kde3 installed

[Alexander Neundorf]

Hi,

On Tuesday 23 May 2006 23:37, Adriaan de Groot wrote:
> 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_LI
>BRARY_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:
>
> 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

Is this all ? There should be more directories listed for the rpath.
Actually this should be handled by cmake. I guess the problem is that in the 
line:
target_link_libraries(dcopidl2cpp  ${QT_QTCORE_LIBRARY} ${QT_QTXML_LIBRARY} 
DCOP)

cmake doesn't really know whether we mean the library DCOP installed on the 
system or the library DCOP built in kdelibs. It seems it picks the wrong one 
for you.
I tried to reproduce it with the testcase which is attached, but this works as 
expected.
It creates a libm.so and links the executable to this library "m" and 
to /lib/libdl.so.2, so that in /lib/ also libm exists. But cmake gets it 
right here.
Does it work for you, Adriaan ?


> 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?

Executables which have to be run from the builddir are built with 
kde4_add_executable(dcopidl2cpp RUN_UNINSTALLED ...)
This has the effect that they are built with RPATh pointing to the builddir, 
and they are relinked when installing with RPATH pointing to the install dir. 
The relinked executables/libs don't overwrite the originally executables/libs 
built by the normal user, so there are not conflicts.

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-rpath-testcase.tar.gz
Type: application/x-tgz
Size: 385 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060524/c8dd12be/attachment.bin