cmake RPATH only applied to first dependency
up vote
0
down vote
favorite
I have been working on compiling an executable which has 2 shared object dependencies. I have stored both .so files in the same directory as the executable, so I set the INSTALL_RPATH property of my executable to "$ORIGIN" and it succeeds at finding one library but not the other.
set_property(TARGET testExecutable PROPERTY INSTALL_RPATH "$ORIGIN")
I used LD_DEBUG to help trouble shoot this problem. The first dependency is located as expected:
70397: find library=lib1.so [0]; searching
70397: search path=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls:/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin (RUNPATH from file ./myproject-install/bin/testExecutable)
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/lib1.so
But for the second dependency, the specified RPATH is not even searched.
70397: find library=lib2.so [0]; searching
70397: search cache=/etc/ld.so.cache
70397: search path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib (system search path)
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/lib2.so
70397: trying file=/lib/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/lib2.so
70397: trying file=/usr/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/lib2.so
70397: trying file=/usr/lib/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/lib2.so
I think the key is that the search for lib1 states (RUNPATH from file ./myproject-install/bin/testExecutable) whereas the search for lib2 states (system search path)
I don't understand why the RPATH differs for the 2 libraries, when the RPATH property was set for the TARGET, which does not change.
The failing library comes from an ExternalProject which has been linked. The other is created within this cmake script.
cmake runtime-error dynamic-linking
add a comment |
up vote
0
down vote
favorite
I have been working on compiling an executable which has 2 shared object dependencies. I have stored both .so files in the same directory as the executable, so I set the INSTALL_RPATH property of my executable to "$ORIGIN" and it succeeds at finding one library but not the other.
set_property(TARGET testExecutable PROPERTY INSTALL_RPATH "$ORIGIN")
I used LD_DEBUG to help trouble shoot this problem. The first dependency is located as expected:
70397: find library=lib1.so [0]; searching
70397: search path=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls:/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin (RUNPATH from file ./myproject-install/bin/testExecutable)
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/lib1.so
But for the second dependency, the specified RPATH is not even searched.
70397: find library=lib2.so [0]; searching
70397: search cache=/etc/ld.so.cache
70397: search path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib (system search path)
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/lib2.so
70397: trying file=/lib/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/lib2.so
70397: trying file=/usr/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/lib2.so
70397: trying file=/usr/lib/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/lib2.so
I think the key is that the search for lib1 states (RUNPATH from file ./myproject-install/bin/testExecutable) whereas the search for lib2 states (system search path)
I don't understand why the RPATH differs for the 2 libraries, when the RPATH property was set for the TARGET, which does not change.
The failing library comes from an ExternalProject which has been linked. The other is created within this cmake script.
cmake runtime-error dynamic-linking
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have been working on compiling an executable which has 2 shared object dependencies. I have stored both .so files in the same directory as the executable, so I set the INSTALL_RPATH property of my executable to "$ORIGIN" and it succeeds at finding one library but not the other.
set_property(TARGET testExecutable PROPERTY INSTALL_RPATH "$ORIGIN")
I used LD_DEBUG to help trouble shoot this problem. The first dependency is located as expected:
70397: find library=lib1.so [0]; searching
70397: search path=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls:/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin (RUNPATH from file ./myproject-install/bin/testExecutable)
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/lib1.so
But for the second dependency, the specified RPATH is not even searched.
70397: find library=lib2.so [0]; searching
70397: search cache=/etc/ld.so.cache
70397: search path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib (system search path)
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/lib2.so
70397: trying file=/lib/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/lib2.so
70397: trying file=/usr/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/lib2.so
70397: trying file=/usr/lib/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/lib2.so
I think the key is that the search for lib1 states (RUNPATH from file ./myproject-install/bin/testExecutable) whereas the search for lib2 states (system search path)
I don't understand why the RPATH differs for the 2 libraries, when the RPATH property was set for the TARGET, which does not change.
The failing library comes from an ExternalProject which has been linked. The other is created within this cmake script.
cmake runtime-error dynamic-linking
I have been working on compiling an executable which has 2 shared object dependencies. I have stored both .so files in the same directory as the executable, so I set the INSTALL_RPATH property of my executable to "$ORIGIN" and it succeeds at finding one library but not the other.
set_property(TARGET testExecutable PROPERTY INSTALL_RPATH "$ORIGIN")
I used LD_DEBUG to help trouble shoot this problem. The first dependency is located as expected:
70397: find library=lib1.so [0]; searching
70397: search path=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls/x86_64:/home/me/software/myproject/build/myproject-install/bin/tls:/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin/x86_64:/home/me/software/myproject/build/myproject-install/bin (RUNPATH from file ./myproject-install/bin/testExecutable)
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/tls/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/x86_64/lib1.so
70397: trying file=/home/me/software/myproject/build/myproject-install/bin/lib1.so
But for the second dependency, the specified RPATH is not even searched.
70397: find library=lib2.so [0]; searching
70397: search cache=/etc/ld.so.cache
70397: search path=/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64/x86_64:/lib/tls/x86_64:/lib/tls/x86_64:/lib/tls:/lib/x86_64/x86_64:/lib/x86_64:/lib/x86_64:/lib:/usr/lib/tls/x86_64/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64/x86_64:/usr/lib/x86_64:/usr/lib/x86_64:/usr/lib (system search path)
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/tls/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64-linux-gnu/lib2.so
70397: trying file=/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/x86_64/lib2.so
70397: trying file=/lib/tls/lib2.so
70397: trying file=/lib/x86_64/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/x86_64/lib2.so
70397: trying file=/lib/lib2.so
70397: trying file=/usr/lib/tls/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/x86_64/lib2.so
70397: trying file=/usr/lib/tls/lib2.so
70397: trying file=/usr/lib/x86_64/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/x86_64/lib2.so
70397: trying file=/usr/lib/lib2.so
I think the key is that the search for lib1 states (RUNPATH from file ./myproject-install/bin/testExecutable) whereas the search for lib2 states (system search path)
I don't understand why the RPATH differs for the 2 libraries, when the RPATH property was set for the TARGET, which does not change.
The failing library comes from an ExternalProject which has been linked. The other is created within this cmake script.
cmake runtime-error dynamic-linking
cmake runtime-error dynamic-linking
asked Nov 9 at 22:13
Ryan
235
235
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02
add a comment |
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
The solution was to set the RPATH for both lib1.so and for lib2.so. I think the issue may have actually been that lib1 also depends on lib2, so the search was not initiated by testExecutable, rather by lib1, a dependency of testExecutable.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
The solution was to set the RPATH for both lib1.so and for lib2.so. I think the issue may have actually been that lib1 also depends on lib2, so the search was not initiated by testExecutable, rather by lib1, a dependency of testExecutable.
add a comment |
up vote
0
down vote
The solution was to set the RPATH for both lib1.so and for lib2.so. I think the issue may have actually been that lib1 also depends on lib2, so the search was not initiated by testExecutable, rather by lib1, a dependency of testExecutable.
add a comment |
up vote
0
down vote
up vote
0
down vote
The solution was to set the RPATH for both lib1.so and for lib2.so. I think the issue may have actually been that lib1 also depends on lib2, so the search was not initiated by testExecutable, rather by lib1, a dependency of testExecutable.
The solution was to set the RPATH for both lib1.so and for lib2.so. I think the issue may have actually been that lib1 also depends on lib2, so the search was not initiated by testExecutable, rather by lib1, a dependency of testExecutable.
answered Nov 9 at 23:32
Ryan
235
235
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53233933%2fcmake-rpath-only-applied-to-first-dependency%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Possible duplicate of Why does the same executable use different RUNPATHs for different library lookups?
– Employed Russian
Nov 10 at 4:26
yea looks like the same problem and solution
– Ryan
Nov 11 at 5:02