Avoid CMAKE linking against @rpath and use absolute paths instead

Question

Build

I am building a CMAKE executable and link against an external library.

For the library I have a custom FindMYLIB cmake scribt that sucessfully sets MYLIB_LIBRARIES variable. promting

MESSAGE("${MYLIB_LIBRARIES}")

correctly yields

/usr/local/lib/libmylib.dylib

I link my executable using

target_link_libraries(my_executable
        ${MYLIB_LIBRARIES}
        )

No custom settings in regards to RPATH are set anywhere in my toolchain or CMAKE code.

Problem

Running it gives me the error

dyld[94833]: Library not loaded: @rpath/libmylib.dylib
  Referenced from: <3747E824-3D4B-38A3-BFD8-E96891349DD5> /path/to/my_executable
  Reason: no LC_RPATH's found

Upon inspecting what is linked I read

$ otool -L /path/to/my_executable
/path/to/my_executable:
    ...
    @rpath/libmylib.dylib (compatibility version 0.0.0, current version 0.0.0)
    ...
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)

The following does NOT occur and IS MISSING

$ otool -l /path/to/my_executable
[...]
Load command NN
          cmd LC_RPATH
      cmdsize 32
         path /usr/local/lib (offset 12)

Mitigation

I found out that the following fixes the executable by setting LC_RPATH explicitly:

install_name_tool -add_rpath /usr/local/lib /pyth/to/my_executable

Question

How do I avoid having a link against @rpath in the first place and use absolute paths instead? Since CMAKE is in possesion of absolute paths, how do they end up as relative links?

Building the same on another machine produceds only absolute paths.

Setup

Mac OSX, M1 cmake 3.23.2 AppleClang 15

Further Details

I have a symbolic link libmylib.dylib -> libmylib-XX.YY.ZZ.dylib

wheras the first is found in CMAKE and the second occurs as linked name.

Unsuccessful so far

several CMAKE flags, including CMAKE_SKIP_RPATH

EDIT 1

set(CMAKE_EXE_LINKER_FLAGS "-Wl,-rpath,/usr/local/lib")

makes the executable run.

It mitigates the issue of not having /usr/local/lib as rpath, but does not resolve my issue of rpaths being installed.

EDIT 2

Minimal example

# CMakeLists.txt

cmake_minimum_required(VERSION 3.12)
project(test_exe)

add_executable(test_exe main.cpp)

target_include_directories(test_exe
        PRIVATE /usr/local/include)

target_link_libraries(test_exe
        PRIVATE
        /usr/local/lib/libmylib.dylib
        )

// main.cpp

#include <mylib/version.hxx>

int main()
{
    return 0;
}

Linker:

/usr/bin/c++
    -g
    -arch
    arm64
    -isysroot
    /Library/Developer/CommandLineTools/SDKs/MacOSX14.0.sdk
    -Wl,-search_paths_first
    -Wl,-headerpad_max_install_names

    CMakeFiles/test_exe.dir/main.cpp.o
    -o
    test_exe

    /usr/local/lib/libmylib.dylib

$ otool -L ./cmake-build-debug/test_exe

    @rpath/libmylib.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)

Edit 3

$ otool -L /usr/local/lib/libmylib.dylib

    @rpath/libmylib.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)

So the library knows its own name as an rpath-stuff.

renaming its internal using

install_name_tool -id
    /usr/local/lib/libmylib.dylib
    /usr/local/lib/libmylib.dylib

to have it point to its absolute path resolves the issue in some cases.

My executable links against /usr/local/lib/libmylib.dylib and finds it.

But it is still not runnable as several other .dylib are referenced by libmylib.dylib. I would have to hack all of these. The key issue here is I am unhappy with how my package provider (build2) is building the library.