The common.manylinux_2_34 and common-manylinux_2_34.crosstool includes
were missing from the Makefile, so the sed preprocessor never expanded
them when generating Dockerfiles from .in files. This caused XCC_PREFIX
to be undefined in the aarch64 Dockerfile.
The pypa manylinux_2_34 base image does not provide the msgfmt binary,
causing the git source build to fail. Git translations are not needed
in a build container.
Using -I/usr/include during the crosstool-ng build of libstdc++ pulled
in host x86_64 headers where int64_t is long long, contaminating the
aarch64 cross-build where int64_t should be long. This caused linker
errors for std::__atomic_futex_unsigned_base symbols due to mismatched
C++ name mangling between headers and the built library.
Copy only the required sys/sdt.h headers into /opt/ct-ng-includes and
point CT_CC_GCC_ENABLE_CXX_FLAGS there instead, matching the approach
used by manylinux_2_28-aarch64.
AlmaLinux 9 doesn't package qemu-user-static, so the Dockerfile
downloads the static binary as /usr/bin/qemu-aarch64-static.
The Toolchain.cmake was incorrectly referencing /usr/bin/qemu-aarch64.
Remove CACHE STRING "" from CMAKE_FIND_ROOT_PATH_MODE_PROGRAM,
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY, and CMAKE_FIND_ROOT_PATH_MODE_INCLUDE
to be consistent with all other cross-compilation toolchain files.
New Docker image for building manylinux_2_34 compatible wheels targeting
64-bit ARM (aarch64) architecture.
- Based on AlmaLinux 9 with crosstool-ng 1.27.0 toolchain
- Uses multiarch/qemu-user-static for cross-compilation emulation
- Includes wheel repair script for manylinux compliance
- GCC configured with --disable-gcov (Bug 100289 workaround)
Add a new manylinux_2_28-aarch64 cross-compilation image targeting
AlmaLinux 8 (glibc 2.28) for building portable Python wheels for
aarch64 from x86_64 hosts. Based on the manylinux_2_34-aarch64
variant with adjusted glibc (2.28) and kernel headers (4.18).
Also fix CMAKE_CROSSCOMPILING_EMULATOR in the 2_34 Toolchain.cmake
to use /usr/bin/qemu-aarch64-static (matching what the Dockerfile
actually installs).
The manylinux images can take over a minute to start on spinning disks
(not SSDs) because pre_exec.sh is changing the ownership of all the
python install directories to be writable by the BUILDER_UID. This is
detailed further in #853.
I changed the build steps for manylinux images to add a group called
`builder`, then change the python directories to be owned by the
`builder` group, and group writable. I then changed pre_exec.sh to add
BUILDER_USER to the builder group prior to the gosu switch to become
BUILDER_USER. The result is that BUILDER_USER is in the `builder`
group that can write to the python directories, allowing the user to
install python packages without permission denied errors.
There was one additional change to support this, and that was the
arguments to `gosu` in entrypoint.sh. Previously the arguments were
`$BUILDER_UID:BUILDER_GID`, but providing the gid prevents `gosu` from
loading additional groups (such as `builder`) from /etc/group. I
removed the GID argument to allow `gosu` to pick up additional groups
from /etc/group.
fixes#853
Instead of buildah.
- Simplified workflow: manifest-tool provides a more straightforward command-line interface for creating manifest lists
- Better integration: manifest-tool is specifically designed for manifest list/OCI index creation and management
- Cross-platform compatibility: Works with both Docker v2.2 manifest lists and OCI v1 indexes
- Template-based approach: The --template and --platforms flags provide a cleaner way to specify multi-arch images
Matt McCormick