# Using an external .dyld with incorrect install\_name

**URL:** <https://discourse.cmake.org/t/using-an-external-dyld-with-incorrect-install-name/5314>\
**Category:** Code\
**Tags:** os:macos\
**Created:** [March 28, 2022, 7:05pm UTC](https://discourse.cmake.org/t/using-an-external-dyld-with-incorrect-install-name/5314 "2022-03-28T19:05:29Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ndevenish](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ndevenish/32/943_2.png) [@ndevenish](https://discourse.cmake.org/u/ndevenish)\
**Post date:** [March 28, 2022, 7:05pm UTC](https://discourse.cmake.org/t/using-an-external-dyld-with-incorrect-install-name/5314/1 "2022-03-28T19:05:29Z")

</div>

I’m linking to an external library `/abs/path/lib/libexternal.dylib`. The dylib has it’s `-install_name`/Library ID set to the relative path `"lib/libexternal.dylib"`.

When I link to this from my downstream application, it fails to load the library at run-time, unless I run from the `cwd` or `/abs/path`, because regardless of how I seem to give the `dyld` to the linker the “dependent library install name” is copied directly:

```nohighlight
$ otool -L test.so
test.so:
	test.so (compatibility version 0.0.0, current version 0.0.0)
	lib/libexternal.dylib (compatibility version 0.0.0, current version 0.0.0)

```

Setting CMake `_RPATH*` flags was my first attempt at solving, but doesn’t touch the problem, because this relationship appears to be handled by the linker/loader directly.

Assuming that I cannot “fix” the upstream library on a short timescale (which gets around this by setting `DYLD_LIBRARY_PATH` in all of their scripts), how can I work around this problem in CMake?

Are my only options either fixing upstream, or adding a custom `install_name_tool` compilation step that corrects the search path of my module (to e.g. either absolute or `@rpath/`)?

---

<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:** [March 29, 2022, 1:37pm UTC](https://discourse.cmake.org/t/using-an-external-dyld-with-incorrect-install-name/5314/2 "2022-03-29T13:37:48Z")

</div>

> [@ndevenish](#):
>
> Setting CMake `_RPATH*` flags was my first attempt at solving, but doesn’t touch the problem, because this relationship appears to be handled by the linker/loader directly.

Right. macOS only uses any RPATH setting for `@rpath/` library IDs.

> [@ndevenish](#):
>
> I’m linking to an external library `/abs/path/lib/libexternal.dylib`. The dylib has it’s `-install_name`/Library ID set to the relative path `"lib/libexternal.dylib"`.

This is just broken.

I recommend using `install_name_tool` to fix the external’s ID to at least use `@rpath/` as a prefix. You can then provide an rpath setting to get it found in your project. Fixing upstream would be even better, but you can fix the ID locally at least in the meantime.