How to create a manylinux2014_x86_64 wheel

Python Help
1

It seems aws lambda can/may/will support python C extensions if they are modeled as manylinux2014_x86_64.

However, I need a single package which supplies windows wheels and source but no manylinux wheels.

I can compile a wheel locally, but the result depends on my installation of the underlying dynamic libraries (ie .so).

Is there a way for me to insert those libraries into the simple x86_64 wheel of the package to convert it into a multilinux wheel?

Or do I need to fork the original source and use cibuildwheel to make the needed manylinux wheel?

2

PEP 513 explains how manylinux works or at least how the original version works and you can see information for newer versions at manylinux.

You need to build the wheel in a manylinux docker container and then run auditwheel to bundle and relink the .so files. It might be easiest to use cibuildwheel but either way you don’t need to fork the project. You can just make a shell script that sets the environment variables and runs cibuildwheel.

3

I would also ask the project if they would accept a PR that adds linux wheels to their build matrix since the work involved is pretty much the same and potentially benefits more people.

4

If I can get the linu2014 wheel built I could consider trying to upstream it.

However, I tried to use the latest linux2014_x86_64 image to do the build.

The wheel built fine and I was able to repair it, but auditwheel show reports it as being compatible with manylinux_2_17_x86_64 and I am not sure how to force the 2014 compatibility or even whether this wheel is compatible.


pycairo-1.28.1-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
is consistent with the following platform tag:
"manylinux_2_17_x86_64".

The wheel references external versioned symbols in these
system-provided shared libraries: libc.so.6 with versions
{'GLIBC_2.3.4', 'GLIBC_2.14', 'GLIBC_2.3.2', 'GLIBC_2.2.5',
'GLIBC_2.3', 'GLIBC_2.7', 'GLIBC_2.4', 'GLIBC_2.8', 'GLIBC_2.11'},
libpthread.so.0 with versions {'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, librt.so.1 with versions {'GLIBC_2.2.5'},
libm.so.6 with versions {'GLIBC_2.2.5'}, libpng15-ce838cd1.so.15.13.0
with versions {'PNG15_0'}, libuuid-f64cda11.so.1.3.0 with versions
{'UUID_1.0'}

This constrains the platform tag to "manylinux_2_17_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.```
5

manylinux2014 and manylinux_2_17 are equivalent. The naming standard went through a few iterations before finally settling on the glibc version (the 2_17 means glibc 2.17) as the identifier. If you look at the description for manylinux2014 it says:

Built wheels are also expected to be compatible with other distros using glibc 2.17 or later, including:

6

Thanks, so I have actually built my required wheel. I guess the real test is if it works in an AWS lambda.