# macOS: LC\_RPATH not set anymore

**URL:** https://discourse.cmake.org/t/macos-lc-rpath-not-set-anymore/6648
**Category:** Code
**Created:** [October 12, 2022, 8:18am UTC](https://discourse.cmake.org/t/macos-lc-rpath-not-set-anymore/6648 "2022-10-12T08:18:19Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![ocroquette](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/o/dbc845/32.png) [@ocroquette](https://discourse.cmake.org/u/ocroquette)
#### Post date: [October 12, 2022, 8:18am UTC](https://discourse.cmake.org/t/macos-lc-rpath-not-set-anymore/6648/1 "2022-10-12T08:18:19Z")

</div>

Hi,

I have a pretty complex project built on macOS. It uses IMPORTED shared libraries, as well as internal ones. The dependency graph is pretty big, but basically, the internal dylibs are depending on the imported ones and on each other, the executables are depending on imported and built libraries.

CMAKE\_MACOSX\_RPATH is set to TRUE, and the executables have LC\_RPATH entries with all the directories of the dependencies, either in the build tree for targets of the project, or on the host for IMPORTED ones. So far so good, the executables can be started directly from the build tree.

Now comes the issue: we just consolidated the dependencies in the project: removing outdated ones, adding explicit ones where required, moving them between PUBLIC and PRIVATE as required… After this refactoring, the LC\_RPATH is not set on the executables anymore. I could trace the issue down to build.ninja.

Before:

```auto
LINK_LIBRARIES = -Wl,-rpath,/path/of/a -Wl,-rpath,/path/of/b -Wl,-rpath,/path/of/imported.dylib lib/a.dylib lib/b.dylib /path/of/imported.dylib -framework Cocoa …

```

After:

```auto
LINK_LIBRARIES = lib/a.dylib lib/b.dylib /path/of/imported.dylib -framework Cocoa …

```

Note that the “-Wl,-rpath” are now missing. Not only those for the transitive dependencies, also for direct ones.

I do not understand why. We did not change the RPATH options, just the dependency tree. The dependencies are still correct, because the executables can be linked. Only the LC\_RPATH are missing, leading to a runtime error:

```auto
dyld: Library not loaded: @rpath/a.dylib
  Referenced from: /path/to/build/tree/bin/excutable
  Reason: image not found

```

One of the executable is defined in its own sub-project(). I removed the project() statement as an experiment, and then the LC\_RPATH was set again. I do not understand that either. It would be a workaround, but I would prefer a proper fix.

Any hint would be appreciated…

Thanks!

Olivier

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 16, 2022, 2:36pm UTC](https://discourse.cmake.org/t/macos-lc-rpath-not-set-anymore/6648/2 "2022-10-16T14:36:45Z")

</div>

It’s interesting that a `project()` call interferes here. A small reproducer would help us to track things down. @brad.king any ideas?

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [October 17, 2022, 2:47pm UTC](https://discourse.cmake.org/t/macos-lc-rpath-not-set-anymore/6648/3 "2022-10-17T14:47:31Z")

</div>

Please post instructions to reproduce the problem from a small test project.