# Why does find\_library use PATH instead of LD\_LIBRARY\_PATH?
**URL:** https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808
**Category:** Usage
**Created:** [January 10, 2024, 1:56am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808 "2024-01-10T01:56:56Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@elahav](https://discourse.cmake.org/u/elahav)
#### Post date: [January 10, 2024, 1:56am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/1 "2024-01-10T01:56:56Z")
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
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 10, 2024, 9:34pm UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/2 "2024-01-10T21:34:04Z")
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?
---
### Author:  [@elahav](https://discourse.cmake.org/u/elahav)
#### Post date: [January 10, 2024, 10:21pm UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/3 "2024-01-10T22:21:41Z")
Built and deployed 3.28.1 from git. Here’s the relevant output:
```auto
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.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [January 11, 2024, 8:47pm UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/4 "2024-01-11T20:47:16Z")
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.
---
### Author:  [@elahav](https://discourse.cmake.org/u/elahav)
#### Post date: [January 11, 2024, 8:58pm UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/5 "2024-01-11T20:58:57Z")
Thanks, Craig.
Still seems odd to me that `PATH` is searched at all, let alone before `LD_LIBRARY_PATH`.
–Elad
---
### Author:  [@Lecris](https://discourse.cmake.org/u/Lecris)
#### Post date: [October 18, 2024, 6:42am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/6 "2024-10-18T06:42:56Z")
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.
---
### Author:  [@vindicator](https://discourse.cmake.org/u/vindicator)
#### Post date: [January 16, 2025, 3:03pm UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/7 "2025-01-16T15:03:13Z")
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:
```auto
/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
```auto
/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 //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:
```auto
/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:
```auto
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?
---
### Author:  [@solemnPonie0](https://discourse.cmake.org/u/solemnPonie0)
#### Post date: [August 5, 2025, 5:00am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/8 "2025-08-05T05:00:50Z")
I am having the same issue.
It is quite ridiculous.
If I set CMAKE\_FIND\_USE\_SYSTEM\_ENVIRONMENT\_PATH to FALSE, binaries for clang++ and such are not found. If I set it to TRUE, libraries for unrelated /opt/-compiled programs from PATH are picked up.
Is there a way to make this work on UNIX the way it is expected to work? binaries from PATH, libraries from LD\_LIBRARY\_PATH?
---
### Author:  [@solemnPonie0](https://discourse.cmake.org/u/solemnPonie0)
#### Post date: [August 5, 2025, 9:50am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/10 "2025-08-05T09:50:53Z")
> `find_library` uses `PATH` to locate programs, not shared libraries
–debug-find proves that it does use PATH to search for both programs and shared libraries
> `LD_LIBRARY_PATH` affects runtime linking, not library discovery.
well, this sounds contradictory
---
### Author:  [@elahav](https://discourse.cmake.org/u/elahav)
#### Post date: [August 5, 2025, 10:26am UTC](https://discourse.cmake.org/t/why-does-find-library-use-path-instead-of-ld-library-path/9808/11 "2025-08-05T10:26:34Z")
> `LD_LIBRARY_PATH` affects runtime linking, not library discovery.
It’s true that `LD_LIBRARY_PATH` on a \*NIX system is meant to be used by the runtime linker, but CMake uses the variable as a hint for finding the paths that need to be passed to the build-time linker. That’s a reasonable approach. The issue reported here is that it also uses `PATH`, which is odd, and then that it uses `PATH` in preference to `LD_LIBRARY_PATH`, which can cause problems.