You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: The _portable_lib.so Python extension built on CI couldn't find PyTorch libraries when installed locally because it had hardcoded absolute paths from
the CI build environment.
Error:
ImportError: dlopen(.../_portable_lib.cpython-311-darwin.so, 0x0002):
Library not loaded: @rpath/libtorch_python.dylib
Referenced from: .../executorch/extension/pybindings/_portable_lib.cpython-311-darwin.so
Reason: tried: '/Users/runner/work/_temp/.../torch/lib/libtorch_python.dylib' (no such file)
Root Cause: The CMake build was linking to PyTorch libraries using absolute paths from the build environment, without setting proper relative RPATHs for
runtime library resolution.
Solution: Added platform-specific relative RPATH settings to the portable_lib target in /Users/mnachin/executorch/CMakeLists.txt (lines 657-669):
- macOS: Uses @loader_path/../../../torch/lib to find PyTorch libraries relative to the .so file location
- Linux: Uses $ORIGIN/../../../torch/lib for the same purpose
- Sets both BUILD_RPATH and INSTALL_RPATH to ensure consistency
Impact: This allows the wheel-packaged _portable_lib.so to find PyTorch libraries regardless of the installation location, fixing the runtime linking issue
when using ExecutorTorch wheels built on CI.
Note: The same fix may be needed for _training_lib if it experiences similar issues.
0 commit comments