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... Thanks for investigating, Ludo’.
