feature: add musllinux_1_2_armv7l

[mayeut]

No description provided.

[bigcat88]

If you need help with this - I can try to help

[mayeut]

@bigcat88,

Tanks for the proposition and sorry for the long silence, I wanted to get a clearer picture before asking for help.

The blockers for this are all related to armv8l vs armv7l:

The first step would be to confirm that they can be considered the same and if you can help with that, it would be greatly appreciated.
armv7l builds will work on armv8l but the other way around might not be true. I think it's only dependent on wether you're running a 32-bit or 64-bit kernel (in 32-bit mode for the latter) and should have no impact on what can run in user-land but is that really the case (it might update some default compiler options in various build systems) ?

If they can't be considered the same - in this context -, there's really not much that can be done IMHO.

If they can be considered the same, auditwheel shall remap armv8l to armv7l

In any case, pip / packaging shall allow installation of armv7l packages on armv8l (maybe related to pypa/packaging#476)

[mayeut]

This is really a hugly hack and should not be required for the image to be usable IMHO.

[mayeut]

This should only be temporary.

[bigcat88]

The first step would be to confirm that they can be considered the same and if you can help with that, it would be greatly appreciated.

Probably I do not understand the question. armv8l is always 64 bit. Exception from this is only Cortex-A32 but it should be ignored, imho.

armv7l builds will work on armv8l but the other way around might not be true.

How armv7l build supposed to work on armv8l? Maybe here I am not understand, did you mean by build the build process of a wheel?

If someone will install 32 bit Python on Alpine 64-bit, then only in that case it will use armv7l wheels.
Or it is for case when 32 bit Alpine get installed on armv8l?

[mayeut]

Probably I do not understand the question. armv8l is always 64 bit. Exception from this is only Cortex-A32 but it should be ignored, imho.

ARM v8 is a microarchitecture https://en.wikipedia.org/wiki/ARM_architecture_family#Armv8 that supports both 32-bit and 64-bit ISA (some chips are only 32-bit, some only 64-bit).

AArch64 provides user-space compatibility with Armv7-A, the 32-bit architecture, therein referred to as "AArch32" and the old 32-bit instruction set, now named "A32". The Thumb instruction set is referred to as "T32" and has no 64-bit counterpart. Armv8-A allows 32-bit applications to be executed in a 64-bit OS, and a 32-bit OS to be under the control of a 64-bit hypervisor.

The linux kernel reports aarch64 for those 64-bit chips. When changing personality through linux32, the kernel will report armv8l (this is the same kind of things as x86_64 becomes i686).

Here we leverage the fact that AWS Graviton 2 can indeed run 32-bit code in user-space (we use an armv7 base image).

The fact that armv7l can run on armv8l is per spec. The other way around is not true. If some build system detects armv8l, it might generate 32-bit code that can't run on armv7l.

[mayeut]

Let's merge this & see if we get feedback on the armv8l vs armv7l comment that remains.