Pip: strip symbols in manylinux wheel repair - #6525
Merged
Merged
Conversation
auditwheel repair --strip runs strip -s on grafted libs and extension modules; saves ~9 MB unpacked / ~1.2 MB compressed per Linux wheel.
Grantim
approved these changes
Aug 5, 2026
oitel
approved these changes
Aug 5, 2026
| sys.executable, "-m", "auditwheel", | ||
| "repair", | ||
| "--plat", f"manylinux_{manylinux_version}_{platform.machine()}", | ||
| "--strip", # drop .symtab/.strtab (~9 MB unpacked); MR libs are built unstripped |
auditwheel --strip runs after patchelf and corrupts ELF load command alignment (import failed on every distro); stripping the source libs before repair avoids that ordering.
Fedr
added a commit
that referenced
this pull request
Aug 7, 2026
`--icf=safe` can only fold functions the compiler placed in a section of their own: without `-ffunction-sections` that is just the COMDAT ones (templates, inlines), while plain out-of-line functions share one `.text` per translation unit and never fold. Gated with the ICF flag inside the `MESHLIB_HAVE_LLD` block, non-Debug only, and restricted to C/C++ via `$<COMPILE_LANGUAGE:C,CXX>` so nvcc never receives it. Stripped shared libraries shrink 2.0% on both arches: -921,600 B on x64, -917,504 B on arm64. The saving is mostly exception-handling tables rather than code — `.gcc_except_table` -845 KB x64 / -917 KB arm64 against about -56 KB of `.text`. `libMeshLibC2.so` alone drops its LSDA section by 79% (1,045,892 -> 220,576) while its `.text` is byte-identical: the generated C bindings are thousands of near-identical try/catch wrappers, so their unwind tables are duplicates even where the surrounding code is not. Unstripped arm64 builds grow 2.7% instead, entirely from per-function section symbols in `.symtab`/`.strtab`. Those are not SEC_ALLOC, are never loaded at runtime, and are removed by `strip` — which every shipped artifact gets: wheels via #6525, the AppImage from linuxdeploy. The `linux-vcpkg` tar.xz is the exception, since `scripts/distribution_vcpkg.sh` does not strip; its compressed delta is unmeasured.
Fedr
added a commit
that referenced
this pull request
Aug 7, 2026
The linux-vcpkg tar.xz was the last artifact shipping unstripped libraries: the wheels (#6525) and the AppImage (linuxdeploy strips unless NO_STRIP is set) have always been stripped. `.symtab`/`.strtab` are not SEC_ALLOC, are never loaded at runtime, and linking against the package needs only `.dynsym`, which strip keeps. The archive shrinks 1,504,076 B on x64 (-2.19%) and 2,131,340 B on arm64 (-3.26%); an unpacked install shrinks by the full 16.3 MB / 17.6 MB of symbol tables. This also removes the only place where `-ffunction-sections` (#6550) inflated `.symtab` visibly. Third-party libraries copied from vcpkg are left alone: blanket-stripping that tree would hit `.a` archives, where it breaks linking. Backtraces inside the shipped libraries now lose the names of non-exported functions, as is already the case for every wheel and AppImage we publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Strip symbols from MeshLib's own libraries (
libMR*.so, the pybind stubs lib, and the module extensions) before building the manylinux wheels. The vcpkg-built third-party libraries andmrmeshpy.soitself are already stripped; our libs were the only unstripped ones —.symtab+.strtabare ~21% oflibMRMesh.so..dynsymis untouched, so runtime symbol resolution is unaffected; the only cost is that native frames from our libs in user crash dumps lose names, same as the third-party libs today.The stripping deliberately happens before
auditwheel repairrather than via auditwheel's own--stripflag: auditwheel strips after patchelf-ing the grafted libs, and stripping a patchelf'ed library corrupts its ELF load command alignment. A first attempt with--stripbuilt fine but the wheel failed to import on every distro withImportError: libTKernel-….so.7.9.1: ELF load command address/offset not page-aligned(run 31016844725).pip-build doesn't run on PRs, so this was verified with a dry
pip-builddispatch from this branch, macOS/Windows legs disabled (run 31020073470): both manylinux builds green, and all 14manylinux-pip-testjobs (Rocky 8, Debian 11, Ubuntu 22.04/25.10, Fedora 37/39/42 × x86_64/aarch64) installed the stripped wheel and passed the Python test suite.Resulting x86_64 wheel from that run vs the published 3.1.3.429 wheel:
libMRMesh.solibMRViewer.solibMRVoxels.soThe download win is modest (symbol string tables compress ~7:1), the installed-size win is ~8 MB.
Windows is unaffected (PDBs are never packed), and delocate has no equivalent hook on macOS, so those wheels are unchanged for now.