Try to get nightly wheel build work with qnn #14633
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/14633
Note: Links to docs will display an error until the docs builds have been completed. ❌ 4 New Failures, 2 Cancelled Jobs, 7 Pending, 1 Unrelated FailureAs of commit ec21edd with merge base 68b2d3c ( NEW FAILURES - The following jobs have failed:
CANCELLED JOBS - The following jobs were cancelled. Please retry:
FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
bot
added
the
CLA Signed
This PR needs a
|
cccclai
force-pushed
the
night_wheel_qnn
branch
from
a393bad to
89d8237
Compare
| RPM_PATH = pathlib.Path("/tmp/glibc.rpm") | ||
| WORKDIR = pathlib.Path("/tmp/glibc-extracted") |
There was a problem hiding this comment.
Can you use tmpdir pacakge?
There was a problem hiding this comment.
I think this code currently applies to both when building the wheel package and user install the wheel package. If we use tmpdir package, it will affect the user's side. The path will be different every time users run this code and they need to do the process again.
There was a problem hiding this comment.
Wait what do you mean? Even when users do pip install setup.py, storing in this temp artifact is only for the during of pip insta.... Is that right?
There was a problem hiding this comment.
users do pip install setup.py
Do you mean user install or use wheel package? Like do you mean 1) pip install executorch_xx.whl or 2) building the wheel packages (python setup bdist)?
| elif is_linux_x86(): | ||
| # On Linux/Unix, prefer $XDG_CACHE_HOME, fallback to ~/.cache | ||
| base = pathlib.Path( | ||
| os.environ.get("XDG_CACHE_HOME", pathlib.Path.home() / ".cache") | ||
| ) |
|
@pytorchbot cherry-pick --onto release/1.0 -c critical |
Our current nightly/release wheel package is done following https://github.com/pytorch/test-infra/wiki/Using-Nova-Reusable-Build-Workflows As described by https://github.com/pytorch/test-infra/blob/5398e1a00c39939f43251f29031c37e6d0c84647/.github/workflows/build_wheels_linux.yml#L4, The docker image infra team used to release nightly/release package is from https://github.com/pypa/manylinux, and it's currently using https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux_2_28-almalinux-8-based. It means the glibc version is 2.28 and GCC is 14. The issue is that, QNN .so files are not compatible with 2.28. The minimum version is 2.34 (I tried 2.29 the first time when it failed and asked for 2.29, but it still fails). In this PR, instead of checking glibc and failed directly when minimum version isn't matched, we will download the glibc 2.34 to /tmp. A different strategy compared with glibc++ is that, we don't load them, because the python process itself start with the system glibc 2.28. We need to re-execute the process with the new glibc (cherry picked from commit 19be2a3)
Cherry picking #14633The cherry pick PR is at #14734 and it is recommended to link a critical cherry pick PR with an issue. The following tracker issues are updated: Details for Dev Infra teamRaised by workflow job |
Our current nightly/release wheel package is done following https://github.com/pytorch/test-infra/wiki/Using-Nova-Reusable-Build-Workflows
As described by https://github.com/pytorch/test-infra/blob/5398e1a00c39939f43251f29031c37e6d0c84647/.github/workflows/build_wheels_linux.yml#L4, The docker image infra team used to release nightly/release package is from https://github.com/pypa/manylinux, and it's currently using https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux_2_28-almalinux-8-based. It means the glibc version is 2.28 and GCC is 14.
The issue is that, QNN .so files are not compatible with 2.28. The minimum version is 2.34 (I tried 2.29 the first time when it failed and asked for 2.29, but it still fails).
In this PR, instead of checking glibc and failed directly when minimum version isn't matched, we will download the glibc 2.34 to /tmp. A different strategy compared with glibc++ is that, we don't load them, because the python process itself start with the system glibc 2.28. We need to re-execute the process with the new glibc