-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix dynamic linking issues with prebuilt pip packages #3049
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/3049
Note: Links to docs will display an error until the docs builds have been completed. ❌ 5 New FailuresAs of commit 358a03f with merge base d3326a2 (): NEW FAILURES - The following jobs have failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
Building wheels: |
516ba48
to
ae1a658
Compare
de14f34
to
ae1a658
Compare
ba3b0a4
to
f99f0cf
Compare
aa9965d
to
0a7566d
Compare
To test out a prebuilt wheel on Linux or macOS:
If you see
|
52afdb2
to
aca550b
Compare
PASS |
aca550b
to
5cf96f5
Compare
I ran into some issues on my Mac m1: https://gist.github.com/larryliu0820/7f95f711c2a40835c3e39680a7a6e44d From @dbort: |
5cf96f5
to
2a58198
Compare
Added a smoke test script to the wheel-build job: succeeding for the expected-compatible python versions, like 3.10 for linux and 3.10 for mac |
libtorch.so builds with the old glibc ABI, so we need to as well, for any source files that include torch headers.
pip wheels will need to be able to find the torch libraries. On Linux, the .so has non-absolute dependencies on libs like "libtorch.so" without paths; as long as we `import torch` first, those dependencies will work. But Apple dylibs do not support non-absolute dependencies, so we need to tell the loader where to look for its libraries. The LC_LOAD_DYLIB entries for the torch libraries will look like "@rpath/libtorch.dylib", so we can add an LC_RPATH entry to look in a directory relative to the installed location of our _portable_lib.so file. To see these LC_* values, run `otool -l _portable_lib*.so`.
The executorch build system will ensure that .dylib/.so files have LC_LOAD_DYLIB and LC_RPATH entries that will work when they're installed. Delocating (i.e., making copies of the .dylibs that ET's libs depend on) will break any libs that depend on the torch libraries if users ever import both `torch` and the executorch library. Both import paths must load exactly the same file, not just a copy of it.
This script is run by CI after building the executorch wheel. Before running this, the job will install the matching torch package as well as the newly-built executorch package and its dependencies. For now we test the export of a simple model, and try executing it using the runtime pybindings. Test Plan: ``` ./install_requirements.sh python build/packaging/smoke_test.py ```
9eed1f6
to
358a03f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the test
Successfully ran the test script under WSL running Ubuntu 20.04.4 LTS on Windows 10 22H2, AMD Ryzen 7 2700 Eight-Core Processor 3.20 GHz, 32GB RAM |
@dbort We expect the prebuilt works for 3.10 only right? |
That's the main version that we need to work. Currently there's no way to disable the python versions that we don't expect to work (like 3.8 and 3.12). |
We can now prebuild pip packages, but we're hitting issues when importing pybindings and torch at runtime.
More context in T185860350
Test Plan
release/0.2
pull_request.paths
entry for a given build-wheels workflow:executorch/.github/workflows/build-wheels-m1.yml
Lines 5 to 8 in 90d0c1a
test
channel (using the pytorch release pip package) instead of thenightly
channelciflow/binaries/all
to the PR so that it builds for all versions of python and not just 3.8 (which doesn't work for executorch)