Enable Python builds

[dbluhm]

It would be great to get python builds of this library set up and published to PyPI. I notice that there's already a section for build-py in the build GHA that is just commented out; could this be as simple as uncommenting those lines?

Related to #26? @blu3beri

[berendsliedrecht]

We still need to make some minor changes to the wrapper in order to be fully compatible again. It already has been done for the Node.JS wrapper so we would just copy the work we did there.

[dbluhm]

This is extending into areas where I don't have a lot of experience but wanted to call out that the current binaries being built and published in releases are incompatible with common python images (used by ACA-Py) due to libc version mismatches. This was tested with python:3.9-slim-buster and python:3.9-slim-bullseye.

On bullseye, we get (the version actually available is 2.31):

/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/local/lib/python3.9/site-packages/anoncreds/libanoncreds.so)

On buster, we get (the version actually available is 2.28):

/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/local/lib/python3.9/site-packages/anoncreds/libanoncreds.so)

cc @swcurran

[berendsliedrecht]

This likely relates to #105. That means that compiling using cross would be the solution.

[andrewwhitehead]

Yes, there's actually a check in the library build using auditwheel to make sure that the resulting library is compatible with the manylinux standard.

[dbluhm]

We tested out building with cross locally and found that we needed to use a different image to get things working. We ended up using this one: https://github.com/rust-cross/manylinux-cross/pkgs/container/manylinux2014-cross/58150916?tag=x86_64-amd64

[andrewwhitehead]

Hm, yes I see the auditwheel check isn't working as intended right now.

aries_askar-0.2.8.dev1-py3-none-manylinux2014_aarch64.whl is consistent with the following platform tag: "manylinux_2_31_x86_64".

The wheel references external versioned symbols in these system-provided shared libraries: libm.so.6 with versions {'GLIBC_2.29'}, libdl.so.2 with versions {'GLIBC_2.17'}, libgcc_s.so.1 with versions {'GCC_4.2.0', 'GCC_3.0', 'GCC_3.3'}, libpthread.so.0 with versions {'GLIBC_2.17'}, libc.so.6 with versions {'GLIBC_2.17', 'GLIBC_2.28', 'GLIBC_2.18'}

This constrains the platform tag to "manylinux_2_31_x86_64". In order to achieve a more compatible tag, you would need to recompile a new wheel from source on a system with earlier versions of these libraries, such as a recent manylinux image.

[dbluhm]

I believe this is implemented.