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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, when using arm-unknown-linux-gnueabihf, users frequently try to install packages for the armhf Debian architecture, objects which are compiled for ARMv7-A, and therefore are not compatibility with ARMv6 platforms such as the Raspberry Pi 0. This differs from the soft-float targets, where packages for the armel architecture are compiled for the ARMv5TE architecture, and therefore are compatible with ARMv5TE, ARMv6, and ARMv7 soft-float targets.
Deny-listing all packages for the armhf architecture prevents issues such as in #1017, where the use of ARMv7 system packages are linked to the binary, so the resulting binary can no longer be executed on an ARMv6 platform. This is difficult to detect until the user attempts to use the generated objects (binaries, libraries) on native hardware.
Marking as a draft since I haven't tested this logic extensively, and denylists an entire architecture, so it's likely a good idea to be careful. Also, we might want to do this for a few musl targets in case if installing system packages can affect their dynamic linking (since this has been an issue with x86_64, see #902).
Note that this currently only affects the hard-float, ARMv6 glibc target. However, it may not be a bad idea to also deny the musl target as well (let me test to see if there can be cross-contamination like with x86_64). No other target has such a confusing overlap with system packages.
This seems like a decent solution, as long as it's mentioned in docs somewhere (in case I forget about this and try installing a package that I know exists but it can't find), also I'm not sure if it is mentioned somewhere but a note that at least the :armhf packages are built for armv7 and that for armv6 might need to be compiled from source would also be good.
This seems like a decent solution, as long as it's mentioned in docs somewhere (in case I forget about this and try installing a package that I know exists but it can't find), also I'm not sure if it is mentioned somewhere but a note that at least the :armhf packages are built for armv7 and that for armv6 might need to be compiled from source would also be good.
I've added documentation on the pinned packages on the wiki, and where we use them. I added the arm-unknown-linux-gnueabihf example as well since I'm assuming this will be merged: if not, we should still document this lack of compatibility somewhere.
The musl images don't need to deny the Debian system packages as expected since the musl sysroot is different, and the compiler doesn't try to link to those packages.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alexhuszagh
added
no changelog
Currently, when using
arm-unknown-linux-gnueabihf, users frequently try to install packages for thearmhfDebian architecture, objects which are compiled for ARMv7-A, and therefore are not compatibility with ARMv6 platforms such as the Raspberry Pi 0. This differs from the soft-float targets, where packages for thearmelarchitecture are compiled for the ARMv5TE architecture, and therefore are compatible with ARMv5TE, ARMv6, and ARMv7 soft-float targets.Deny-listing all packages for the
armhfarchitecture prevents issues such as in #1017, where the use of ARMv7 system packages are linked to the binary, so the resulting binary can no longer be executed on an ARMv6 platform. This is difficult to detect until the user attempts to use the generated objects (binaries, libraries) on native hardware.Also linked is #426.