# How to set dyld path via FindPackage(Boost)?
**URL:** https://discourse.cmake.org/t/how-to-set-dyld-path-via-findpackage-boost/13323
**Category:** Usage
**Tags:** os:macos
**Created:** [January 2, 2025, 8:44pm UTC](https://discourse.cmake.org/t/how-to-set-dyld-path-via-findpackage-boost/13323 "2025-01-02T20:44:11Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Vdaleke](https://discourse.cmake.org/u/Vdaleke)
#### Post date: [January 2, 2025, 8:44pm UTC](https://discourse.cmake.org/t/how-to-set-dyld-path-via-findpackage-boost/13323/1 "2025-01-02T20:44:11Z")
I encountered a problem:
I have myself-built boost libraries which FindBoost module finds perfectly, but when I look built binary with `otool -L` I see not full paths of boost libraries, but only their names:
```auto
(venv) ➜ target git:(fix/refactor-gitignore-and-readme) ✗ otool -L Desbordante_test
Desbordante_test:
libboost_graph-xgcc14-mt-a64-1_86.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_container-xgcc14-mt-a64-1_86.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_thread-xgcc14-mt-a64-1_86.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/gcc/lib/gcc/current/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.33.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)
```
At the same time when I use Apple Clang and Homebrew boost the binary looks like:
```auto
(venv) ➜ Desbordante git:(apple-clang-buildability) ✗ otool -L build/target/Desbordante_test
build/target/Desbordante_test:
/opt/homebrew/opt/boost/lib/libboost_graph.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/boost/lib/libboost_container.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/boost/lib/libboost_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.105.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
```
Actually, In first case there is no problem with `Desbordante_test`, it finds boost libraries in `usr/local/include` fine and I don’t know why? But another binary with same `otool -L` output which is Python module not works:
```auto
>>> import desbordante
Traceback (most recent call last):
File "", line 1, in
ImportError: dlopen(/Users/vdaleke/Documents/desbordante-core/venv/lib/python3.12/site-packages/desbordante.cpython-312-darwin.so, 0x0002): Library not loaded: libboost_container-xgcc14-mt-a64-1_86.dylib
Referenced from: <5DE266BA-6882-3835-BB89-3E13967FF861> /Users/vdaleke/Documents/desbordante-core/venv/lib/python3.12/site-packages/desbordante.cpython-312-darwin.so
Reason: tried: 'libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), 'libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), '/usr/lib/libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file, not in dyld cache), '/Users/vdaleke/Documents/desbordante-core/libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/vdaleke/Documents/desbordante-core/libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), '/Users/vdaleke/Documents/desbordante-core/libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file), '/usr/lib/libboost_container-xgcc14-mt-a64-1_86.dylib' (no such file, not in dyld cache)
```
And another binary built with brew boost and Apple Clang works fine.
So, i’m trying to understand how brew forces path into DYLD\_PATH and do it too. And other question is how FindBoost module find brew boost in `opt/homebrew` without any hints?
Thank you.
---
### Author:  [@krasznaa](https://discourse.cmake.org/u/krasznaa)
#### Post date: [January 8, 2025, 10:10am UTC](https://discourse.cmake.org/t/how-to-set-dyld-path-via-findpackage-boost/13323/2 "2025-01-08T10:10:07Z")
Dear Matvey,
I wanted to write here, since by chance I was dealing with a very similar thing around `BoostConfig.cmake` in the last few days. Though I fear that my very specific setup/solution will not help you too much in the end. 🙁
As you probably know, CMake gives no direct support for projects modifying their runtime environments. Most simple projects don’t need to do this to begin with, so this seems fair. But in our own setup we have to generate a runtime environment based on what external projects CMake used to build our code. (It’s a long story…) We do this by our CMake configuration generating `setup.sh` scripts that get installed along with our binaries. So that one has to `source` the appropriate script from the appropriate installation directory, to use that version of our software in a terminal session. (Again, longer story in the background here.)
As it happens, the recent change in CMake 3.30 with deprecating `FindBoost.cmake` (which itself is a quite understandable move) made things a bit difficult for us with this as well. Since while `FindBoost.cmake` provides a `Boost_LIBRARY_DIRS` variable that we could easily use in our environment setup scripts, `BoostConfig.cmake` coming with the Boost installations, has no such thing. 😢 So I had to write some code that would figure out the library directory from stuff that `BoostConfig.cmake` does provide. (In the unlikely case that you’d be interested in the details of this, I’m happy to share what I did.)
With all this being said… On macOS you should really just be thinking about setting [RPATH](https://en.wikipedia.org/wiki/Rpath) correctly on your binaries. 🤔 Apple clearly decided a while ago that `DYLD_LIBRARY_PATH` is evil, and every binary should hard-code in itself with absolute path names what libraries it will want to load at runtime. (Making relocating binaries quite the pain…) So as long as you don’t absolutely need to use `DYLD_LIBRARY_PATH` for some reason, the following should get you started with setting up the use of RPATH in your build configuration:
[https://duerrenberger.dev/blog/2021/08/04/understanding-rpath-with-cmake/](https://duerrenberger.dev/blog/2021/08/04/understanding-rpath-with-cmake/)
Cheers,
Attila