Add support to release aarch64 wheels

[odidev]

Problem

On aarch64, ‘pip install pycapnp’ builds the wheels from source code and then installs it. It requires the user to have a development environment installed on his system. Also, it takes some time to build the wheels than downloading and extracting the wheels from pypi.

Resolution

On aarch64, ‘pip install pycapnp’ should download the wheels from pypi.

@haata and @Team Please let me know your interest in releasing aarch64 wheels. I can help in this.

[haata]

I'll push out a release once I can get the other manylinux2010 wheels upgraded to manylinux2014 (manylinux2010 is now EOL).

[bobrik]

On aarch64 the library is also explicitly linked against a specific capnp version when you build with new enough capnp installed:

# ldd /usr/local/lib/python3.9/dist-packages/capnp/lib/capnp.cpython-39-aarch64-linux-gnu.so
	linux-vdso.so.1 (0x00007fffb4a48000)
	libcapnpc-0.9.1.so => /usr/lib/aarch64-linux-gnu/libcapnpc-0.9.1.so (0x00007fffb4823000)
	libcapnp-rpc-0.9.1.so => /usr/lib/aarch64-linux-gnu/libcapnp-rpc-0.9.1.so (0x00007fffb471e000)
	libcapnp-0.9.1.so => /usr/lib/aarch64-linux-gnu/libcapnp-0.9.1.so (0x00007fffb4668000)
	libkj-async-0.9.1.so => /usr/lib/aarch64-linux-gnu/libkj-async-0.9.1.so (0x00007fffb4591000)
	libkj-0.9.1.so => /usr/lib/aarch64-linux-gnu/libkj-0.9.1.so (0x00007fffb44ff000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x00007fffb42e2000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x00007fffb42bd000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x00007fffb4142000)
	/lib/ld-linux-aarch64.so.1 (0x00007fffb4a15000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x00007fffb4112000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x00007fffb4066000)

Compare this to x86_64 version installed via pip, which is presumably built with a bundled capnp:

ldd /usr/local/lib/python3.9/dist-packages/capnp/lib/capnp.cpython-39-x86_64-linux-gnu.so
	linux-vdso.so.1 (0x00007fff088fd000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1c4f9ac000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1c4f7df000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1c4f69b000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1c4f681000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1c4f65f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c4f498000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1c50023000)

[LloydW93]

It looks like for M1 this was fixed with a --force-bundled-libcapnp: f45a9d0 or, potentially the same fix could be done for general aarch64.

[haata]

https://pypi.org/project/pycapnp/2.0.0/#files should be working now.