Fix Jsonnet Library Loading On MacOS#170
Conversation
Jsonnet libraries from Spack have incorrect install_name entries on macOS (bare filenames instead of @rpath-relative paths). This prevents the dynamic linker from finding them at runtime despite correct RPATH settings in executables. Add logic to Findjsonnet.cmake to detect and fix these libraries during CMake configuration using install_name_tool, ensuring they use @rpath-relative references compatible with macOS dyld.
There was a problem hiding this comment.
Pull request overview
This PR adds a macOS-specific workaround to Findjsonnet.cmake to fix incorrect install_name entries in Jsonnet libraries installed via Spack. The fix runs during CMake configuration, detecting libraries with bare filename install_names and updating them to use @rpath-relative paths using install_name_tool.
Key changes:
- Added macOS-specific logic to detect and fix malformed install_name entries in jsonnet libraries
- Uses otool to inspect library install_names and install_name_tool to correct them
- Only fixes libraries with install_names that don't start with
@or/(relative paths)
Modules/Findjsonnet.cmake
Outdated
| ) | ||
| endif() | ||
| endif() | ||
|
|
There was a problem hiding this comment.
Remove this trailing blank line. Files must end with exactly one newline character and no trailing blank lines.
There was a problem hiding this comment.
@copilot open a new pull request to apply changes based on this feedback
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #170 +/- ##
==========================================
- Coverage 81.42% 80.79% -0.64%
==========================================
Files 115 115
Lines 2046 2046
Branches 330 330
==========================================
- Hits 1666 1653 -13
- Misses 252 258 +6
- Partials 128 135 +7
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
greenc-FNAL
left a comment
There was a problem hiding this comment.
I have concerns about using one package's CMake to fix an external package's libraries. I realize this is on MacOS, which is generally single-user and local access, but there is the possibility of failure if the installed package is on CVMFS, and race conditions if the user has local agents running e.g. through VSCode.
Is this being paired with a fix to the Spack recipe?
|
@phlexbot format |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This looks like multiple issues:
It would be great to have the Spack recipe for jsonnet build well-formed libraries, but that is a bigger fix than I wanted to handle now. This is a fix limited to our own code that solves the current problem.
We do not now use CVMFS on macOS, and I do not think we have any reason to do so. Given that, is there still a race condition problem? I do not think so.
It does not depend on a fix to the Spack recipe. Fixing the recipe is a larger task. |
Jsonnet libraries from Spack have incorrect install_name entries on macOS (bare filenames instead of @rpath-relative paths). This prevents the dynamic linker from finding them at runtime despite correct RPATH settings in executables.
Add logic to Findjsonnet.cmake to detect and fix these libraries during CMake configuration using install_name_tool, ensuring they use @rpath-relative references compatible with macOS dyld.