-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When a single wheel contains multiple top-level packages, auditwheel creates separate .libs dirs for each of them #89
Comments
Maybe we should put the shared libs in Or we could arbitrarily pick one of the subpackages to contain the |
If it was called ${WHEELNAME}_libs then it could go into platlib like any other module. |
Yes, the advantage to using a |
Hmm, well, I guess the only way to find out is to try. How would one get the name of the wheel inside |
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. An example is shown below. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
If you have a package that contains multiple C extensions that depend on the same shared libraries, then `delocate-wheel` saves duplicate copies of all of the shared libraries. This makes for packages that are several times larger than necessary. This patch causes `delocate-wheel` to sweep up all of the dependencies and put them in a single directory, rather than creating duplicates. The convention is based on the proposal in pypa/auditwheel#89 and pypa/auditwheel#90.
Bug originally filed by @lpsinger at pypa/manylinux#156:
If you have a package that contains multiple C extensions that depend on the same shared libraries, then
auditwheel repair
saves duplicate copies of all of the shared libraries. An example is shown below.This makes for packages that are several times larger than necessary. Could
auditwheel repair
sweep up all of the dependencies and put them in a single.libs
directory, rather than creating duplicates?Example
The text was updated successfully, but these errors were encountered: