I’m building Qt6, which uses the FindZLIB.cmake module to find libz.so. It ends up finding it in the wrong place. When I tried debugging I noticed that the environment-based paths the cmake uses are based on the PATH variable (which it then strips of /bin), not the LD_LIBRARY_PATH one. Should it not be using the latter?
This is cmake 3.25 on QNX.
Thanks,
–Elad
That’s a bit surprising. CMake 3.3 added the behavior where find_library() considered locations based on PATH, but it was reverted for non-Windows platforms in CMake 3.6. The latest release (CMake 3.28) reverted it for Windows as well. I don’t know what the implications are for QNX, but if you still see the behavior with CMake 3.28, could you show the debug output from your test which demonstrates PATH still being used in the search?
Built and deployed 3.28.1 from git. Here’s the relevant output:
CMake Debug Log at CMakeLists.txt:4 (find_library):
find_library called with the following settings:
VAR: ZLIB_LIBRAY
NAMES: "z"
Documentation: Path to a library.
Framework
Only Search Frameworks: 0
Search Frameworks Last: 0
Search Frameworks First: 0
AppBundle
Only Search AppBundle: 0
Search AppBundle Last: 0
Search AppBundle First: 0
CMAKE_FIND_USE_CMAKE_PATH: 1
CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH: 1
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH: 1
CMAKE_FIND_USE_CMAKE_SYSTEM_PATH: 1
CMAKE_FIND_USE_INSTALL_PREFIX: 1
find_library considered the following locations:
/data/home/elahav/bin/libz(\.so|\.a)
/proc/boot/libz(\.so|\.a)
/system/bin/libz(\.so|\.a)
/usr/lib/libz(\.so|\.a)
/usr/libz(\.so|\.a)
/lib/libz(\.so|\.a)
The item was found at
/system/lib/libz.so
-- Configuring done (0.3s)
-- Generating done (0.0s)
-- Build files have been written to: /data/home/elahav/src/cmake_test/build
elahav@meddle:~/src/cmake_test/build$ echo $PATH
/data/home/elahav/bin:/proc/boot:/system/bin
elahav@meddle:~/src/cmake_test/build$ echo $LD_LIBRARY_PATH
/system/lib:/system/lib/dll
It still seems to consider PATH first. I removed /proc/boot/libz.so so it doesn’t find it (/proc/boot is the image file system, the QNX equivalent of an initial ramdisk), but would have detected that copy of the library first had it still been there.
I miscalled the situation regarding PATH usage. According to the latest find_library() docs, PATH is still searched. Only some of the additional paths based on PATH were removed. Here’s the relevant part of the docs which explain why you’re seeing PATH being used:
Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is passed or by setting the CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to FALSE.
- The directories in LIB and PATH.
On Windows hosts, CMake 3.3 through 3.27 searched additional paths: /lib/ if CMAKE_LIBRARY_ARCHITECTURE is set, and /lib for each /[s]bin in PATH, and /lib for other entries in PATH. This behavior was removed by CMake 3.28.
Thanks, Craig.
Still seems odd to me that PATH is searched at all, let alone before LD_LIBRARY_PATH.
–Elad
If you try to build a project that is cross os compatible you will quickly find out how strange it is to make windows work, among them PATH takes the role of LD_LIBRARY_PATH such that it needs to point to the folder with the .dll files it needs to load. Regarding the order, wouldn’t it generally be fine, because on non-windows environments the PATH would point to the executables and should not have any .so files that would interfere with it.
I just came across this as well…
I was compiling a jami project (dhtnet) and came across an oddity.
It compiled fine until it hit linking, where it failed because:
/usr/bin/ld: warning: libcrypto.so.3, needed by /usr/lib/libsrt.so.1.5, may conflict with libcrypto.so.1.0.0
/usr/bin/ld: /usr/local/lib/libpj-x86_64-unknown-linux-gnu.a(ssl_sock_ossl.o): undefined reference to symbol 'X509_get_version@@OPENSSL_3.0.0'
/usr/bin/ld: /usr/lib/libcrypto.so.3: error adding symbols: DSO missing from command line
But that shouldn’t be, so I traced the cmake setup and saw
/usr/share/cmake/Modules/FindPkgConfig.cmake(302): find_library(pkgcfg_lib_pjproject_ssl NAMES ssl HINTS /usr/local/lib NO_DEFAULT_PATH )
/usr/share/cmake/Modules/FindPkgConfig.cmake(306): find_library(pkgcfg_lib_pjproject_ssl NAMES ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(309): mark_as_advanced(pkgcfg_lib_pjproject_ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(310): if(pkgcfg_lib_pjproject_ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(311): list(APPEND _libs /<pathTo>/STM32CubeProgrammer/bin/libssl.so )
Yeah, some brainwit at ST thought it best to shove libraries in the bin dir.
At the same time, I don’t think find_library should be going through PATH for “libraries”.
Once I removed that STM32 bin dir from my PATH, I successfully got:
/usr/share/cmake/Modules/FindPkgConfig.cmake(302): find_library(pkgcfg_lib_pjproject_ssl NAMES ssl HINTS /usr/local/lib NO_DEFAULT_PATH )
/usr/share/cmake/Modules/FindPkgConfig.cmake(306): find_library(pkgcfg_lib_pjproject_ssl NAMES ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(309): mark_as_advanced(pkgcfg_lib_pjproject_ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(310): if(pkgcfg_lib_pjproject_ssl )
/usr/share/cmake/Modules/FindPkgConfig.cmake(311): list(APPEND _libs **/usr/lib/libssl.so** )
Setting -DCMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH=FALSE results in the root bin dir not being searched AT ALL:
Make Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
I know I can set those but like @elahav was saying, it’s odd/non-sensical for find_library to seach bin dirs for libs (at least before lib dirs first). It’s the same kind of non-sensical thinking as ST shoving libs into their bin dir.
I believe this to be considered a bug and think it ought to be reported as such, no?