Build Python wheels for aarch64 using QEMU

[adavis444]

Python linux wheels for aarch64 were originally introduced in #1678, then later removed in #3381.

As stated in issues #1677 and #4407, building from source is slow for developers and may not be possible on some machines.

These changes add aarch64 wheel support.
They do not introduce building extensions for aarch64, analogous to the current behavior for musllinux and i686 builds.

Resolves #1677
Resolves #4407

[Mause]

Hey there, have you tested this on your fork at all? My tests using this technique last year ended up timing out after running for over six hours

[adavis444]

Hey there, have you tested this on your fork at all? My tests using this technique last year ended up timing out after running for over six hours

I ran into unrelated errors that I suspected (whether correctly or not) may be due to environment differences in GitHub Actions that might not occur in the main duckdb repo. So the results of the tests running against this PR will indicate its validity.

At first glance, #4519 would appear to have been successful. Are there results available with details of the timeouts that have not expired?

[Mause]

Your unrelated errors are due to tags missing from your fork I think?

While I was able to successfully build in the end, the issue with those successful builds was that they didn't conform to the manylinux specifications, so would have been unusable by most people

[carlopi]

Your unrelated errors are due to tags missing from your fork I think?

I think so, this should end up somewhere in the docs eventually, should be something like:

git fetch --tags
git push your_remote v0.8.0

[adavis444]

Thank you both for that info! I've pushed the tags to my fork accordingly.

On my fork the job Python 3 Linux (x86_64, cp310-*, false) is failing the test test_extension_loading with the error
duckdb.InvalidInputException: Invalid Input Error: Extension "/project/httpfs/httpfs.duckdb_extension" version (v..1-dev) does not match DuckDB version (0.8.1-dev356)
on this line.

Is there a straightforward resolution to this error?

[adavis444]

This appears to be resolved on the second attempt as a result of the tags being pushed:
Compare v..1-dev on Attempt #1 with v0.8.1-dev356 on Attempt #2

[Mause]

@adavis444 it looks like your builds timed out in the same way that my ones did unfortunately

[adavis444]

https://github.com/duckdb/duckdb/actions/runs/5201519274

Python 3 Linux (aarch64, cp310-*, false)
The job running on runner GitHub Actions 18 has exceeded the maximum execution time of 360 minutes.

Although that is unfortunate and consistent with past results, I'm encouraged by the completion of
Building cp310-manylinux_aarch64 wheel on the line ✓ cp310-manylinux_aarch64 finished in 9889.17s, even though Building cp310-musllinux_aarch64 wheel did not complete.

I'm experimenting with the separation of the manylinux builds from the musllinux builds on my fork here.

[adavis444]

Given that, when isolated, manylinux wheels were able to build successfully
(see jobs Python 3 Linux (cp37, manylinux, aarch64, false) and Python 3 Linux (cp310, manylinux, aarch64, false))
whereas musllinux wheels were not
(see jobs Python 3 Linux (cp37, musllinux, aarch64, false) and Python 3 Linux (cp310, musllinux, aarch64, false)),

it would be reasonable to provide manylinux aarch64 wheels and hold off on musllinux aarch64 wheels until either musllinux wheels are available for numpy and pandas or a more appropriate runner is available.

[Mause]

Okay, that does look promising, keep us in the loop!

[Mause]

Well, this looks all green, consider me impressed!

@Mytherin it'd be amazing to have this in the bug fix release 😉

[Mytherin]

Let's give it a shot on the nightly.

Thanks for the contribution!

[Qiuzhuang]

I am able to use cross-compile via crossenv(https://crossenv.readthedocs.io/) and aarch64 toolchains in the x86_64 host. This compilation is fast. Here are steps:

1. In Ubuntu 20, download toolchains gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz from https://storage.googleapis.com/mirror.tensorflow.org/developer.arm.com/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz and add aarch64-linux-gnu-* into path.
2. build the host python as from crossenv. Command is as follows,
   ./configure
   CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ CPP='aarch64-linux-gnu-g++ -E'
   --host=aarch64-linux-gnu
   --build=x86_64-linux-gnu
   ac_cv_buggy_getaddrinfo=no
   ac_cv_file__dev_ptmx=yes
   ac_cv_file__dev_ptc=no
   --enable-optimizations
   --prefix=/aarch64/python3.8

then make && make install

3. create the crossenv venv:
   python3 -m crossenv /aarch64/python3.8/bin/python3 cross_venv
   . /cross_venv/bin/activate

4. install packages like wheel.

5. python3 setup.py build_ext -j 12 bdist_wheel

As a result, this build the aarch64 wheel, it takes about 10 mins in my machine.

The build package is tested in the ARM64 cortex-A35.