> Andreas Enge <andr...@enge.fr> skribis: > >> RUNPATH >> /gnu/store/7c30kyzagk84inhnb2nbxcmnh76xgh6c-ktouch-4.14.2/lib:/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib64:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib:/gnu/store/k7w7wdpvaqlkwq0ijz9149pqn3lq8a5n-gcc-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/../../.. >> >> (Thanks to Ludovic for the suggestion to use objdump!) >> >> The linker line looks like this: >> Linking CXX executable ktouch >> cd /tmp/nix-build-ktouch-4.14.2.drv-0/build/src && >> /gnu/store/sr9lv3vhviy151zv315zdgi2rvq97a9r-cmake-2.8.12/bin/cmake -E >> cmake_link_script CMakeFiles/ktouch.dir/link.txt --verbose=1 >> /gnu/store/13ahaqlmniysmbls5d1fcmzy59yd5xk5-gcc-4.8.3/bin/c++ > > [...] > >> -o ktouch -rdynamic >> /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libkdeclarative.so.5.14.2 >> >> /gnu/store/mipmjv4mpsf3rrsk1mbhpqzlw939v6ny-kdelibs-4.14.2/lib/libplasma.so.3.0.0 >> > > [...] > >> You see lots of "...so" and no "-l...", which is apparently the cmake way of >> doing things. > > Our ld-wrapper is ineffective when the .so file names are passed > directly like this. That is, ld-wrapper adds -rpath for any -l switch, > but it does not add -rpath for libraries whose absolute file name is > specified. > > That could be easily fixed, but in core-updates. > >> But no "-Wl,-rpath" despite >> -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE >> Does this mean that this option only honours paths coming from "-l", while >> at the same time using "-l" is unusual with cmake? > > Uh. While we can improve ld-wrapper, the best would of course be to get > CMake to do the right thing... We have not change ld-wrapper for this right?
And I have add a note to cmake's tracker: http://www.cmake.org/Bug/view.php?id=14974 > > Thanks for investigating, > Ludo’.
