`auditwheel -addtag` failing with "No tags to be added. Exiting"

[julian-smith-artifex-com]

I am building a wheel using cibuildwheel in a manylinux docker image, with platform tag linux_x86_64. But when cibuildwheel runs auditwheel addtag it fails with diagnostic "No tags to be added. Exiting".

Can anyone explain what the diagnostic means, and why auditwheel is failing here? I was hoping that addtag would rename the wheel, e.g. changing the platform tag to manylinux_2_17_x86_64.manylinux2014_x86_64.

The input wheel has .so files created via SWIG. These .so's depend on .so files that are not in the wheel - they are actually in a different wheel (listed as a prerequisite using Requires-Dist in the metadata), hence i'm setting CIBW_REPAIR_WHEEL_COMMAND_LINUX to auditwheel addtag -w {dest_dir} {wheel} to avoid auditwheel failing because it thinks there are missing shared libraries. My build already takes care of setting rpath etc, so i only need auditwheel for platform tag-renaming.

[I'm using this scheme in order to save space on pypi.org - i'm putting my project's shared libraries that are not dependent on Python version (these are very large) in one wheel, and everything else in a second wheel, one for each supported Python version (3.8 - 3.11 at the moment).]

Thanks in advance for any help,

- Julian

[lkollar]

This might be a bug in addtag, but I'm not even sure what this subcommand is useful for. It seems to try to assign the minimum compatible tag in the file name, but from my limited testing it always ends up with the linux_x86_64 tag, which isn't useful. So if you pass a wheel which only has a linux_x86_64 tag, it does nothing, and for wheels which have manylinux tags it also adds linux_x86_64, which isn't very useful either. I wonder if this is a regression, as there aren't any real tests for this functionality...

@julian-smith-artifex-com I don't think you can achieve what you want here with auditwheel. AFAIK there isn't any way to make auditwheel ignore missing .so files. It could also be problematic if you ship these shared libraries in a separate wheel and a different extension loaded into an application using your extension depends on a slightly different versions of some of the same libraries. This will mean that only one version of such libraries will be loaded and both extensions will have to share it, even though one might be ABI incompatible.

This could only work if you also ensure that the shared libs you are shipping in the large wheel have unique SONAME and file name entries, ensuring that nothing else will ever need them, only your library. Auditwheel does this with repair, but that wouldn't work on a dependency-only wheel.

[lkollar]

I'm going to close this as not supported, but feel free to reopen it if you think there is a better way to achieve this.

[julian-smith-artifex-com]

Thanks for the informative reply.

I have things working without using auditwheel, so happy to have this issue closed.