fix(bundle): fix MakeBundle and RPATH issues on Linux#2148
Conversation
fixup_bundle can drop a dangling symlink into bin/ (e.g. libAlembic.so.1.8 whose target stayed in lib/). The cleanup step then ran file(COPY) on it, which fails with "cannot duplicate symlink ... No such file or directory" and aborts `make bundle`. Move each stray lib with file(RENAME) instead: it relocates the symlink as-is (without dereferencing), so the link resolves again once in lib/. Also fix the log line, which referenced the undefined CMAKE_LIST_LENGTH.
On systems where CMAKE_INSTALL_LIBDIR resolves to lib64 and lib64 is a symlink to lib, file(COPY) was reproducing the symlink without its target, leaving a dangling lib64 -> lib in the bundle. Detect IS_SYMLINK, copy the real directory, then recreate the symlink so both names work in the bundle.
\\$ORIGIN in a CMake string produces a literal \$ORIGIN in the binary RPATH, which the dynamic linker does not recognise. A single \$ is sufficient to protect the $ from CMake variable expansion.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request fixes the escaping of $ORIGIN in CMAKE_INSTALL_RPATH within src/CMakeLists.txt. Additionally, it updates src/cmake/MakeBundle.cmake to properly handle symlink directories by copying the real directory and recreating the symlink, and changes the moving of stray libraries from bin/ to lib/ to use file(RENAME) instead of file(COPY) to preserve symlinks. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
1 participant
Summary
Three bugs affecting the
bundletarget on Linux (Rocky/RHEL):Stray libs in
bin/:fixup_bundlemay leave dangling symlinks (e.g.libAlembic.so.1.8) inbin/because their targets remain inlib/.file(COPY)cannot duplicate dangling symlinks; replaced withfile(RENAME)in aforeachloop.lib64 -> libsymlink broken in bundle: on systems whereCMAKE_INSTALL_LIBDIRresolves tolib64(a symlink tolib),file(COPY)reproduced the symlink without copying its target, leaving a danglinglib64 -> libin the bundle. Now detectsIS_SYMLINK, copies the real directory, and recreates the symlink.$ORIGINRPATH written as\$ORIGIN:\\$ORIGINin the CMake string produced a literal\$ORIGINin the ELF RPATH, which the dynamic linker does not recognise as the executable-relative token. Changed to\$ORIGIN(single backslash) which produces the correct$ORIGINin the binary.Test plan
-DALICEVISION_BUILD_DEPENDENCIES=OFFagainst pre-built deps on a Rocky 9 / RHEL systemcmake --build . --target bundleand verify it completes without errorsreadelf -d <bundle>/bin/aliceVision_* | grep RPATHshows$ORIGIN/../lib64:$ORIGINbundle/lib64is a valid symlink pointing to an existingbundle/lib/