auditwheel repair --plat manylinux2014_aarch64

[JonasVautherin]

It seems to me that manylinux2014_aarch64 support was added to auditwheel (see this PR), but when I run:

auditwheel repair --plat manylinux2014_aarch64 my-manylinux2014-aarch64.whl

I get:

auditwheel repair: error: argument --plat: invalid choice: 'manylinux2014_aarch64' (choose from 'linux_x86_64', 'manylinux1_x86_64', 'manylinux2010_x86_64', 'manylinux2014_x86_64')

I am on auditwheel 3.1.1, python 3.8. Is that supported but rejected by the CLI, or is it not supported yet?

[JonasVautherin]

Looking into the codebase, I see it is triggered here.

And the choices come from **kwargs, here:

super().__init__(
            default=default,
            required=required,
            **kwargs
        )

Unfortunately, I don't really understand where that comes from in the first place. It seems like it comes from here:

with open(join(dirname(abspath(__file__)), 'policy.json')) as f:
    _POLICIES = []
    _policies_temp = json.load(f)
    for _p in _policies_temp:
        _name = _p['name'] + '_' + _ARCH_NAME
        if _name in _PLATFORM_REPLACEMENT_MAP or _name.startswith('linux'):
            _p['name'] = _name
            _POLICIES.append(_p)

And hence from this policy.json file, but I can't seem to find it.

So to answer part of my question: it seems that at least the CLI is refusing the platform. It doesn't say whether or not manylinux2014-aarch64 is supported (should it pass this step), though.

[lkollar]

Are you running this on an ARM 64 machine? From the available choices above, it seems this was run on an x86 box. You can only repair wheels on a host with matching architecture.

[JonasVautherin]

Oh, that makes sense now that you say it. I am cross-compiling, from x86_64.

This said, do I actually need to repair a wheel built with manylinux? Or is it fine to just rename it? I tried it on test.pypi.org by just renaming and it seemed fine... In other words, how relevant is auditwheel for manylinux builds?

[mayeut]

This said, do I actually need to repair a wheel built with manylinux? Or is it fine to just rename it? I tried it on test.pypi.org by just renaming and it seemed fine...

For very simple extensions, auditwheel will not change much (but will still do checks before hand):

• Tag in file {distribution}-{version}.dist-info/WHEEL e.g. cp37-cp37m-manylinux2010_x86_64
• Name of the wheel

PyPI only checks the filename (for now). I don't know which checks installers are doing.
Standards implies both, what's actually implemented might be different (and subject to change to enforce standards a bit more).

In other words, how relevant is auditwheel for manylinux builds?

1. auditwheel does checks that the binaries are compliant with the policy requested => prevents incompatible wheels that just would have been renamed to be uploaded.
2. for more complex wheels, auditwheel automatically handles grafting of required dependencies when repairing.

[igo95862]

You can only repair wheels on a host with matching architecture.

Is this a real limitation or just not implemented functionality? The ELF files encode their architecture in the headers and auditwheel is a pure Python module. I am pretty sure it is possible to have some kind of --arch command line option.

I am looking in to the compiling a completely static wheels for many different architectures and spinning containers to just install and run auditwheel seems very inconvenient.

Some tests already do override the arch and libc so functionality is already there:

auditwheel/tests/integration/test_bundled_wheels.py

Line 36 in 7ebf0d2

wheel_policies = WheelPolicies(libc=Libc.GLIBC, arch="x86_64")

[jvolkman]

I am looking in to the compiling a completely static wheels for many different architectures and spinning containers to just install and run auditwheel seems very inconvenient.

@igo95862 You can try repairwheel which uses auditwheel under the hood but aims to support cross-platform repair. I also put together this example which uses it.

[igo95862]

@jvolkman Your project looks interesting but I would like to try upstreaming this functionality of overriding the architecture and libc family in to auditwheel. I can create a merge request if the maintainers are ok with it.