Enable crosscompiling aarch64 python wheels under dockcross manylinux docker image #8280
Conversation
| # when crosscompiling for aarch64, override the default multibuild's repair_wheelhouse logic | ||
| # since "auditwheel repair" doesn't work for crosscompiled wheels | ||
| function repair_wheelhouse { | ||
| echo "Skipping repair_wheelhouse since auditwheel requires build architecture to match wheel architecture." |
There was a problem hiding this comment.
build_wheel() can be modified to use a qemu-aarch64 wrapper with auditwheel:
# Based on multibuild build_wheel_cmd(). The only change is calling the repair_wheelhouse with qemu-aarch64.
function build_wheel_aarch64 {
local cmd=${1:-pip_wheel_cmd}
local repo_dir=${2:-$REPO_DIR}
[ -z "$repo_dir" ] && echo "repo_dir not defined" && exit 1
local wheelhouse=$(abspath ${WHEEL_SDIR:-wheelhouse})
start_spinner
if [ -n "$(is_function "pre_build")" ]; then pre_build; fi
stop_spinner
if [ -n "$BUILD_DEPENDS" ]; then
pip install $(pip_opts) $BUILD_DEPENDS
fi
(cd $repo_dir && $cmd $wheelhouse)
qemu-aarch64 repair_wheelhouse $wheelhouse
}
function build_wheel {
if [ $ARCH == "arm64" ]; then
build_wheel_aarch64 "bdist_wheel_cmd" $@
else
build_wheel_cmd "bdist_wheel_cmd" $@
fi
}
This way you can keep the build and repair process within the container.
There was a problem hiding this comment.
Interesting idea, but are you sure this is actually something that works? It seemed to me that you'd need to be in a aarch64 linux image (with arm-based python and binaries auditwheel uses, e.g. patchelf) for this to work.
|
only one broken test left? way to go & looking forward to the merge! |
|
@dlj-NaN @haberman friendly ping. I'd really like to hear feedback on whether this is an approach we could use (I believe so). I'm aware that before publishing "official" version of the aarch64 wheels we'd need to have some aarch64 tests in place first (I have some ideas around how to set that up aarch64 tests under an emulator), but that is something that should be done in a separate PR. The wheel crosscompilation itself (as presented in this PR) seems quite reasonable to me. If this looks good, we could look into setting up emulated tests as the next step. |
The "Linux C++ Distcheck" failure is very likely unrelated to this PR. |
| local plat_name_flag="--plat-name=$AUDITWHEEL_PLAT" | ||
|
|
||
| # override the value of EXT_SUFFIX to make sure the crosscompiled .so files in the wheel have the correct filename suffix | ||
| export PROTOCOL_BUFFERS_OVERRIDE_EXT_SUFFIX="$(python -c 'import sysconfig; print(sysconfig.get_config_var("EXT_SUFFIX").replace("-x86_64-linux-gnu.so", "-aarch64-linux-gnu.so"))')" |
There was a problem hiding this comment.
It would be neat if you could do something like this:
$(qemu-aarch64 python -c 'import sysconfig; print(sysconfig.get_config_var("EXT_SUFFIX")')
I don't think that would currently work, since qemu won't necessarily have access to its own python... unless I missed something?
There was a problem hiding this comment.
Yes, currently this won't work as there is no arm-specific installation of python in the docker image.
We can revisit things like that in the next iteration (along with figuring out how to run auditwheel checks e.g. under an emulator). I am going to continue looking into improvements like this while I'm experimenting with running protobuf tests under an emulator.
|
@dlj-NaN thanks for the review! Note that once we merge this, the python release builds will start generating the aarch64 wheels automatically (which I think according to your release process will end up uploading aarch64 wheels to pypi once the next release happens). If you want to avoid publishing the aarch64 wheels (until we have more tests in place), we need to explicitly remove them from the list of wheels that get published - let me know if you want me to look into that. |
@dlj-NaN please let me know if I should look into removing the aarch64 wheels from the published set or if it's ok to leave as is (and merge this). |
|
Yes, let's remove the wheels from the distribution until we can test them. |
Until we have a chance to actually verify behavior and stability, it still seems prudent not to include release wheels yet. |
Sounds fair. I have made a small change that puts the aarch64 manylinux artifacts into artifacts/unofficial directory, so that they are still being stored (for manual testing or unofficial releases), but they won't be uploaded to PyPI since the protobuf python release process only considers wheels that are directly under the artifacts/ directory. With this change, the PR should be good to merge. |
is there a link where one can fetch those unofficial releases/wheels? |
They are accessible through the "Linux Python Release" job's artifacts. Unfortunately at this point, the results for those jobs are internal-only. Let's look into making the aarch64 wheels externally accessible as a follow up step. |
👍 |
|
Any ETA for the aarch64 wheels into PyPI ? |
Build crosscompiled aarch64 python wheels under dockcross manylinux2014 image.
Supersedes #8196 (some of the challenges I'm solving in this PR are already described there).
Key points:
I smoke tested the resulting aarch64 wheel manually on a real arm64 machine and I also ran "auditwheel show" and no issues were reported - so I'm quite confident that they work just fine.