My application builds and links with Qt6 picking up the Qt .so files because CMake builds some rpath “magic” into the executable when linking so that the libraries are picked up even though they are not listed in /etc/ld.so.conf.
I don’t use Qt6Network directly.
When I add calls into another .so that requires Qt6Network, and add it to target_link_libraries, it all goes to pot, giving me: /home/amonra/.vs/DSS/out/build/DeepSkyStackerLive/DeepSkyStackerLive: error while loading shared libraries: libQt6Network.so.6: cannot open shared object file: No such file or directory
That external library is built using CMake and installed as /usr/local/lib/libSmtpMime.so.2. Its CMakeLists.txt says:
This looks wrong. CMake will see the ${ORIGIN} and try to evaluate it as a CMake variable, and that’s probably going to be an empty string. You need to specify it without the curly braces:
set(CMAKE_INSTALL_RPATH "$ORIGIN")
Of course, that will only help if the library you’re wanting to find is in the same directory as the binary that needs it, but I assume that’s the situation you are creating, or at least trying to create.
I changed the build of the .so in question as suggested and ran its install. The files libSmtpMime.so.2 and libSmtpMime.so.2.0 were copied to my install dir from /usr/local/lib by qt6_deploy_runtime_dependencies.
All the libQt6xxxxx.so files are this directory. But:
amonra@styx:~/.vs/DSS/x64/Linux/Debug$ ldd libSmtpMime.so
linux-vdso.so.1 (0x00007ffdb7db9000)
libQt6Network.so.6 => not found
libQt6Core.so.6 => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f996452e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f996450a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f99642e1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f99641f8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f99647f0000)
amonra@styx:~/.vs/DSS/x64/Linux/Debug$
From what you said in your reply the other day I thought this should pick up the libs.
Clearly something is either amiss with their CMakeLists.txt content, or something else is wrong.
On Linux, you can run readelf -d <binary-to-analyze> and look at any RUNPATH or RPATH entries. That should tell you what is ending up being embedded in each binary. That should at least help narrow down where to look for something behaving differently to what you expected.
EDIT: Sorry, just saw this is exactly what you did in your last post, which I skipped through too quickly.
It’s not the *.so files you need at run time, it’s the *.so.X where X is some number. You need to find an exact match for what is listed as the NEEDED entries of a binary in the readelf -d output. The *.so files are for the build-time linker, and even then will only be needed if you’re relying on linker search paths (and CMake tries hard to avoid that). The run time loader will look for the NEEDED files, and those file names should match the SONAME embedded in each of those libraries too.
No, as I tried to mention in my earlier comment, the $ORIGIN is for the run time loader, not CMake. The run time loader understands $ORIGIN, I don’t know for sure if it understands ${ORIGIN} (it probably does). Either way, CMake does not understand $ORIGIN as anything to substitute and leaves it alone, so you may as well just use that. Then you don’t have to mess around with escaping.
but when I re-run the CMake, do a ninja clean, ninja, sudo ninja install, the install step says (as I said earlier):
amonra@styx:~/Downloads/SmtpClient-for-Qt/build$ sudo ninja install
[0/1] Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libSmtpMime.so.2.0
-- Installing: /usr/local/lib/libSmtpMime.so.2
-- Set non-toolchain portion of runtime path of "/usr/local/lib/libSmtpMime.so.2.0" to ""
Even though the cmake file says to put the origin stuff there when installing, it is simply wiping it out
amonra@styx:~/Downloads/SmtpClient-for-Qt/build$ cmake --version
cmake version 3.31.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
amonra@styx:~/Downloads/SmtpClient-for-Qt/build$ ninja --version
1.10.1
amonra@styx:~/Downloads/SmtpClient-for-Qt/build$
Let’s eliminate some things. Rather than installing to /usr/local/lib and having to use sudo, let’s try installing to some temporary location that doesn’t need admin privileges. Please wipe your build directory, build again from scratch, and instead of sudo ninja install, please do cmake --install . --prefix staging (from the top level build directory). You should see the project installed to a staging subdirectory of your build directory.
It might also be useful if you can attach the cmake_install.cmake file, the one that installs libSmtpMime.so.2 (you may have to look in subdirectories for the right one).
There’s something strange about the way the SmtpClient target is being defined. I suspect something is clearing out or changing some of its target properties after you’ve set it to what you want. You could try checking the values of some properties at the very end of the top level CMakeLists.txt to see if they still hold the values you expected at that point. I’d check any of the target properties that include RPATH in their name.
The CMAKE_INSTALL_RPATH variable only affects targets created after the variable is set. In other words, it’s the value of that variable at the point add_library() or add_executable() is called that matters. Setting CMAKE_INSTALL_RPATH after those calls won’t affect those targets.
If CMAKE_INSTALL_RPATH is being set in src/CMakeLists.txt rather than the top level CMakeLists.txt file, then it won’t be visible in the top level CMakeLists.txt file. This is normal variable scope behavior.
Normally, you would set CMAKE_INSTALL_RPATH in the top level CMakeLists.txt file, and before any calls to add_subdirectory() or any other command that might result in targets being created. Then it would apply to the whole project consistently.
