auditwheel repair is a tool which automagically vendors shared library dependencies in such a way that:
- the wheel gets a copy of shared library dependencies that aren’t part of the manylinux specification
- the copied library names are made unique (e.g.
libcurl.so.4.6.0is renamed to
libcurl-f60b0aa0.so.4.6.0) to avoid shadowing
- the shared libraries being repaired have their dependencies updated to point to these unique names in the ELF header
- the ELF header is also given a RUN_PATH to the vendored library directory (so no need for
These steps are a very effective strategy to allow a binary built on one variant of a Linux OS to work on many other Linux OSes (manylinux was a pretty accurate name, eh? ). It is also a highly effective strategy to allow two distributions/packages to be installed side-by-side, each with a dependency some shared library X, but potentially at a completely different/incompatible version.
It is this latter case that drives this question - suppose I wanted to install these two packages in development/editable mode. If each depends on shared library X and X has not been uniquely named as a result of an
auditwheel repair (because we don’t have wheels when installing from source) then we arrive at the situation where one of the packages is going to pick up the wrong library X, and a core dump is likely to follow.
What I’d therefore like to be able to do is “auditwheel repair” an editable install such that the powerful steps of
auditwheel repair listed above are applied in-place on the directory structure that I give it. Effectively, I want something akin to:
auditwheel repair-in-situ /path/to/editable/install/location
Am I missing such functionality already existing somewhere? Given
auditwheel's name, and the fact that this has nothing to do with wheels per-se, do you think this something that
auditwheel would be prepared to add? How far from being able to do this is the auditwheel codebase already?