Embedding dylib in a macos bundle

Usage
5

After more trial and error, I was finally able to come up with a satisfactory solution.

First of all, I could never make BundleUtilities/fixup_bundle work. I have a feeling that fixup_bundle ended up removing some rpath in one of the libraries which made it fail to load.

So this is what I came up with. I have no idea whether it is the right approach, but it does work for my use case:

Following Apple’s documentation, I manually updated the 2 libraries that I am using, something like this:

> install_name_tool -id "@rpath/libEGL.dylib" libEGL.dylib
> codesign -s "-" -fv libEGL.dylib

Then I simply link with the modified libraries:

  set(GOOGLE_ANGLE_DIR "${CMAKE_CURRENT_LIST_DIR}/external/google/angle")
  list(APPEND google_angle_libs "${GOOGLE_ANGLE_DIR}/macOS/libEGL.dylib" "${GOOGLE_ANGLE_DIR}/macOS/libGLESv2.dylib")
  target_link_libraries(${target} PRIVATE "${google_angle_libs}")

Then I added a target property to make sure that the rpath is correct:

set_target_properties(${target} PROPERTIES
    INSTALL_RPATH "@executable_path/../Frameworks"
)

And then finally, I copy the libraries during install

install(
    FILES "${google_angle_libs}"
    DESTINATION "$<TARGET_BUNDLE_DIR_NAME:${target}>/Contents/Frameworks"
)

So what happens, is that during the build, cmake generates an executable with the following rpath:

Load command 26
      cmd LC_RPATH
      cmdsize 88
      path /Volumes/Vault/tmp/misc-projects/test-raylib/external/google/angle/macOS (offset 12)

and the libraries are never copied inside the .app (bundle) because they are found in the source tree… So it just works.

During install, due to the property INSTALL_RPATH that is set, cmake will do the right thing and remove the hard-coded rpath and replace it with the correct one and because the libraries are copied inside the bundle (under Contents/Frameworks) they will be found as well:

Load command 29
      cmd LC_RPATH
      cmdsize 48
      path @executable_path/../Frameworks (offset 12)