fix(macOS): skip build-tree RPATH to prevent install_name_tool conflict - #9509
Conversation
|
/backport to stable-33.0 |
There was a problem hiding this comment.
Pull request overview
This PR adjusts macOS bundle build settings to prevent cmake --install from attempting an install_name_tool -delete_rpath on RPATH entries that macdeployqt has already removed during POST_BUILD.
Changes:
- Set
BUILD_WITH_INSTALL_RPATH TRUEfor thenextcloudmacOS bundle target to avoid build-tree RPATH tracking and install-time deletion attempts. - Set
BUILD_WITH_INSTALL_RPATH TRUEfor thenextcloudsync_vfs_suffixplugin target on Apple, addressing the same install-time RPATH deletion conflict aftermacdeployqt.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/libsync/vfs/suffix/CMakeLists.txt |
Ensures the suffix VFS plugin builds using the install RPATH on macOS to avoid install-time install_name_tool conflicts. |
src/gui/CMakeLists.txt |
Ensures the main nextcloud bundle target builds with install RPATH so cmake --install doesn’t try to delete a build-tree RPATH that macdeployqt already removed. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
CMake automatically adds the binary's RUNTIME_OUTPUT_DIRECTORY (work/build/bin) to the nextcloud executable's RPATH at build time. macdeployqt runs as a POST_BUILD step and replaces that path with @loader_path/../Frameworks (the self-contained bundle convention). When cmake --install then runs, it tries to remove the original build-tree RPATH via install_name_tool -delete_rpath, but macdeployqt has already eliminated it, causing: install_name_tool: no LC_RPATH load command with path: .../work/build/bin found in: .../NextcloudDev Set BUILD_WITH_INSTALL_RPATH TRUE on the nextcloud target inside the BUILD_OWNCLOUD_OSX_BUNDLE block. This tells CMake to use the install RPATH (empty for a macOS bundle) during build rather than a separate build-tree RPATH, so no install_name_tool fixup is generated at cmake --install time. Signed-off-by: Iva Horn <[email protected]>
ef5a935 to
d1090ba
Compare
|
Artifact containing the AppImage: nextcloud-appimage-pr-9509.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
|



CMake automatically adds the binary's RUNTIME_OUTPUT_DIRECTORY (work/build/bin) to the nextcloud executable's RPATH at build time. macdeployqt runs as a POST_BUILD step and replaces that path with @loader_path/../Frameworks (the self-contained bundle convention). When cmake --install then runs, it tries to remove the original build-tree RPATH via install_name_tool -delete_rpath, but macdeployqt has already eliminated it, causing:
install_name_tool: no LC_RPATH load command with path:
.../work/build/bin found in: .../NextcloudDev
Set BUILD_WITH_INSTALL_RPATH TRUE on the nextcloud target inside the BUILD_OWNCLOUD_OSX_BUNDLE block. This tells CMake to use the install RPATH (empty for a macOS bundle) during build rather than a separate build-tree RPATH, so no install_name_tool fixup is generated at cmake --install time.