Skip to content
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

Generate correct wheel name for armv8l #1289

Closed
messense opened this issue Nov 23, 2022 · 8 comments
Closed

Generate correct wheel name for armv8l #1289

messense opened this issue Nov 23, 2022 · 8 comments
Labels
wheel Wheel

Comments

@messense
Copy link
Member

See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/41663#note_275648

armv8l is 32-bit mode on aarch64.

root@raspberrypi:~# uname -a
Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux
root@raspberrypi:~# linux32 uname -a
Linux raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 armv8l GNU/Linux
@messense messense added the wheel Wheel label Nov 23, 2022
@nekopsykose
Copy link

for the specific issue there- armv8l wouldn't be the correct name either. it means 32-bit on 64, but the actual wanted output is armv7 (actual 32-bit) - which is the rust toolchain triple (rustc -vV host: line). the uname value should not be the source of truth here, as it's not related to the actual toolchain target.

i'm not sure how it would affect every case, but defaulting to the rustc host instead of uname sounds like it would just always be correct without this edgecase, and then --target can be used for people that cross compile or want to set it manually like now with no change there.

@messense
Copy link
Member Author

Maybe we can just add an escape hatch like _PYTHON_HOST_PLATFORM?

@messense
Copy link
Member Author

See also pypa/packaging#476

@messense
Copy link
Member Author

messense commented Nov 23, 2022

We used to generate armv7l but the Alpine Linux CI will fail to install it because pip wants armv8l, see #490 (comment) and #709

@nekopsykose
Copy link

pip wants armv8l

you mean pip installs things based on the current sysconfig thing that reads uname? inconvenient.. not sure how to really fix it then without adding shims like that everywhere

@messense
Copy link
Member Author

you mean pip installs things based on the current sysconfig thing that reads uname?

Exactly

$ root@raspberrypi:~# linux32 pip debug --verbose
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without notice.
pip version: pip 22.0.4 from /usr/local/lib/python3.9/dist-packages/pip (python 3.9)
sys.version: 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]
sys.executable: /usr/bin/python3
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: linux
sys.implementation:
  name: cpython
'cert' config value: global
REQUESTS_CA_BUNDLE: None
CURL_CA_BUNDLE: None
pip._vendor.certifi.where(): /usr/local/lib/python3.9/dist-packages/pip/_vendor/certifi/cacert.pem
pip._vendor.DEBUNDLED: False
vendored library versions:
  CacheControl==0.12.10
  colorama==0.4.4
  distlib==0.3.3
  distro==1.6.0
  html5lib==1.1
  msgpack==1.0.3 (Unable to locate actual module version, using vendor.txt specified version)
  packaging==21.3
  pep517==0.12.0
  platformdirs==2.4.1
  progress==1.6
  pyparsing==3.0.7
  requests==2.27.1
  certifi==2021.10.08
  chardet==4.0.0
  idna==3.3
  urllib3==1.26.8
  rich==11.0.0 (Unable to locate actual module version, using vendor.txt specified version)
  pygments==2.11.2
  typing_extensions==4.0.1 (Unable to locate actual module version, using vendor.txt specified version)
  resolvelib==0.8.1
  setuptools==44.0.0 (Unable to locate actual module version, using vendor.txt specified version)
  six==1.16.0
  tenacity==8.0.1 (Unable to locate actual module version, using vendor.txt specified version)
  tomli==1.0.3
  webencodings==0.5.1 (Unable to locate actual module version, using vendor.txt specified version)
Compatible tags: 33
  cp39-cp39-linux_armv8l
  cp39-abi3-linux_armv8l
  cp39-none-linux_armv8l
  cp38-abi3-linux_armv8l
  cp37-abi3-linux_armv8l
  cp36-abi3-linux_armv8l
  cp35-abi3-linux_armv8l
  cp34-abi3-linux_armv8l
  cp33-abi3-linux_armv8l
  cp32-abi3-linux_armv8l
  py39-none-linux_armv8l
  py3-none-linux_armv8l
  py38-none-linux_armv8l
  py37-none-linux_armv8l
  py36-none-linux_armv8l
  py35-none-linux_armv8l
  py34-none-linux_armv8l
  py33-none-linux_armv8l
  py32-none-linux_armv8l
  py31-none-linux_armv8l
  py30-none-linux_armv8l
  cp39-none-any
  py39-none-any
  py3-none-any
  py38-none-any
  py37-none-any
  py36-none-any
  py35-none-any
  py34-none-any
  py33-none-any
  py32-none-any
  py31-none-any
  py30-none-any

@JuniorJPDJ
Copy link

JuniorJPDJ commented Nov 27, 2022

Pip already has if path for i686 on x86_64, it should add one for armv7l when armv8l is detected to install correct wheels.

This issue also touches other arches like i386 docker on x86_64 and forced me to do workaround with detection of tag based on elf inside wheel: https://dev.funkwhale.audio/funkwhale/funkwhale/-/blob/7e0aabe62c6efd7687fd9f74819e803adc0f8aeb/.gitlab-ci.yml#L84
Funny thing is that pip generates correct wheel names, but maturin doesn't.
Example can be shown here: https://dev.funkwhale.audio/funkwhale/funkwhale/-/jobs/138405#L977

bors bot added a commit that referenced this issue Nov 27, 2022
1301: Fix wrong platform tag when building in i386 docker container r=messense a=messense

Fixes the i386 issue reported in #1289 (comment).

We can not trust the return value of `uname -m` in Docker container.

Co-authored-by: messense <[email protected]>
bors bot added a commit that referenced this issue Nov 27, 2022
1301: Fix wrong platform tag when building in i386 docker container r=messense a=messense

Fixes the i386 issue reported in #1289 (comment).

We can not trust the return value of `uname -m` in Docker container.

Co-authored-by: messense <[email protected]>
@messense
Copy link
Member Author

messense commented Aug 4, 2023

Closing now that pypa/packaging#690 is merged.

@messense messense closed this as completed Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wheel Wheel
Projects
None yet
Development

No branches or pull requests

3 participants