# swig generated code not finding libraries on macOS 12. rpath issue?

**URL:** <https://discourse.cmake.org/t/swig-generated-code-not-finding-libraries-on-macos-12-rpath-issue/6384>\
**Category:** Code\
**Created:** [September 1, 2022, 7:32pm UTC](https://discourse.cmake.org/t/swig-generated-code-not-finding-libraries-on-macos-12-rpath-issue/6384 "2022-09-01T19:32:35Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![snarkhunter](https://discourse.cmake.org/user_avatar/discourse.cmake.org/snarkhunter/32/2728_2.png) [@snarkhunter](https://discourse.cmake.org/u/snarkhunter)\
**Post date:** [September 1, 2022, 7:32pm UTC](https://discourse.cmake.org/t/swig-generated-code-not-finding-libraries-on-macos-12-rpath-issue/6384/1 "2022-09-01T19:32:35Z")

</div>

Hi –

My project contains swig files that create libraries that need to link to external libraries. Some of the external libraries are obtained via pkgconfig, and `pkg_check_modules` places their (nonstandard) full paths in a variable like `EXT_LINK_LIBRARIES`.

On macOS 11.6, this works to build and link the swig modules:

```auto
swig_add_library(
   ${swigfile} 
   TYPE MODULE
   LANGUAGE PYTHON 
   SOURCES ${swigfile}.i)
target_link_libraries(
   ${swigfile}
   PUBLIC
   ${EXT_LINK_LIBRARIES})

```

On macOS 12.5, however, even though the full path to the libraries was given in `EXT_LINK_LIBRARIES`, when the program tries to import the python module it fails, because it’s only looking for the swig-generated .so file in standard locations (`<prefix>/lib`, `/usr/local/lib`, etc).

On both systems running `otool -L` on the dylib file shows that it’s linking to `@rpath/lib[myswiggedlib].dylib`. I know that something changed with rpath handling in macOS 12, but I haven’t found instructions on how to fix it in this context.

Why is the full path provided to `target_link_libraries` being ignored? Is there an rpath-related fix that I’m missing?

(I’m using cmake 3.23.3 on both systems, with macOS 12.5.1 and Xcode 13.4.1 on an M1, and macOS 11.6.8 and Xcode 13.2 on an Intel Mac.)

Thanks.  
– Steve

---

<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:** [September 1, 2022, 10:22pm UTC](https://discourse.cmake.org/t/swig-generated-code-not-finding-libraries-on-macos-12-rpath-issue/6384/2 "2022-09-01T22:22:32Z")

</div>

> [@snarkhunter](#):
>
> Why is the full path provided to `target_link_libraries` being ignored? Is there an rpath-related fix that I’m missing?

macOS rpath is silly in that `@rpath/` requires using `LC_RPATH` load commands and `LC_RPATH` commands only work on `@rpath/`-using library lookups. If the library wants rpath entries, you’ll have to add the relevant paths to the `CMAKE_*_RPATH` variables yourself.

I’ve wanted “rpath usage requirements” to deal with this, but have never gotten around to actually handling this.

---

<div class="post-metadata">

**Author:** ![snarkhunter](https://discourse.cmake.org/user_avatar/discourse.cmake.org/snarkhunter/32/2728_2.png) [@snarkhunter](https://discourse.cmake.org/u/snarkhunter)\
**Post date:** [September 2, 2022, 4:05pm UTC](https://discourse.cmake.org/t/swig-generated-code-not-finding-libraries-on-macos-12-rpath-issue/6384/3 "2022-09-02T16:05:55Z")

</div>

Ok, thanks.  
– Steve