DH_STRIP(1)

✨ DH_STRIP ✨

okay bestie, welcome to the dh_strip manual page β€” that's section 1 of the Debhelper manuals, and it's literally the glow-up artist for your binaries πŸ’…


πŸ’– NAME πŸ’–

dh_strip β€” strip executables, shared libraries, and some static libraries

yes she takes away. it's giving "you don't need that trauma," but for debug symbols 🫢

πŸŽ€ SYNOPSIS πŸŽ€

dh_strip [debhelper options] [-Xitem] [--dbg-package=package]
[--keep-debug]

πŸ¦‹ DESCRIPTION πŸ¦‹

So dh_strip is a debhelper program, and her whole job? Stripping out debug symbols from executables, shared libraries, and static libraries β€” the ones that, like, nobody needs while the thing is actually running. bye bye bloat ✨

She's a smart girl and does her own recon: she goes through your package build directories and figures out what to strip all on her own. She uses file(1), plus file permissions and filenames, to clock what's what β€” shared libraries (*.so), executable binaries, static libraries (lib*.a), and debugging libraries (lib*_g.a, debug/*.so) β€” and then strips each one as much as possible. (Which, for the debugging libraries, is not at all. she respects them πŸ™ˆ)

ngl, in general her guesses are genuinely really good, and she'll do the right thing in almost all cases. main character intuition fr fr πŸ‘‘

But here's the thing: it's super hard to auto-guess whether a file is a module, and also hard to figure out how to strip a module. So dh_strip does not currently deal with stripping binary modules like .o files. not her era, bestie 😭


✨ OPTIONS ✨

  • -Xitem, --exclude=item β€” Keep any file with item appearing anywhere in its filename out of the stripping party. You can stack this option multiple times to build up your whole exclusion list πŸ’…
  • --dbg-package=package β€” Bestie listen, this one is a now special purpose option that you normally do not need. In most cases there should be little reason to use this option for new source packages, because debhelper automatically generates debug packages ("dbgsym packages"). If you have a manual --dbg-package that you want to replace with an automatically generated debug symbol package, please see the --dbgsym-migration option.

What it does: it makes dh_strip save the debug symbols she strips from the packages she acts on as independent files, living in the package build directory of the debugging package you specify.

For example: if your packages are libfoo and foo, and you want to include a foo-dbg package with debugging symbols, you'd run dh_strip --dbg-package=foo-dbg.

Warning though β€” this option implies --no-automatic-dbgsym and cannot be used with --automatic-dbgsym or --dbgsym-migration. pick a lane 🚫

  • -k, --keep-debug β€” Also a now special purpose option that you normally do not need. Same deal: in most cases there should be little reason to use this option for new source packages, because debhelper automatically generates debug packages ("dbgsym packages"). And if you have a manual --dbg-package you want to swap for an automatically generated debug symbol package, go look at --dbgsym-migration.

What it does: debug symbols get retained, but split off into an independent file in usr/lib/debug/ in the package build directory. --dbg-package is easier to use than this option, but this option is more flexible. your call, hun πŸŽ€

It implies --no-automatic-dbgsym and cannot be used with --automatic-dbgsym.

  • --dbgsym-migration=package-relation β€” This is your glow-up pipeline: it migrates you from a manual "-dbg" package (the kind made with --dbg-package) over to an automatically generated debug symbol package. This option should describe a valid Replaces- and Breaks-relation, which gets added to the debug symbol package so you avoid file conflicts with the (now obsolete) -dbg package. iconic behavior, honestly πŸ’œ

It implies --automatic-dbgsym and cannot be used with --keep-debug, --dbg-package or --no-automatic-dbgsym.

Examples:

dh_strip --dbgsym-migration='libfoo-dbg (<< 2.1-3~)'
dh_strip --dbgsym-migration='libfoo-tools-dbg (<< 2.1-3~), libfoo2-dbg (<< 2.1-3~)'
  • --automatic-dbgsym, --no-automatic-dbgsym β€” These two control whether dh_strip should be creating debug symbol packages when possible. The default is to create debug symbol packages. periodt πŸ’–
  • --ddebs, --no-ddebs β€” Historical name for --automatic-dbgsym and --no-automatic-dbgsym. vintage, but ok πŸŽ€
  • --ddeb-migration=package-relation β€” Historical name for --dbgsym-migration. also vintage 🌸
  • --keep-lto β€” Sections containing information generated by -flto -ffat-lto-objects are normally removed from static archives, because the streaming format changes even in minor GCC versions, and because cross package link time optimizations are normally not desired. This option lets you keep that info in the static libraries instead. preserving the lore πŸ”₯

🌈 NOTES 🌈

If the DEB_BUILD_OPTIONS environment variable contains nostrip, nothing will be stripped, in accordance with Debian policy (section 10.1 "Binaries"). And heads up: this will also inhibit the automatic creation of debug symbol packages. so, like, full stop πŸ›‘

The automatic creation of debug symbol packages can also be prevented by adding noautodbgsym to the DEB_BUILD_OPTIONS environment variable. However β€” and this is the important bit β€” dh_strip will still add debuglinks to ELF binaries when this flag is set. Why? To ensure that the regular deb package will be identical with and without this flag (assuming it is otherwise "bit-for-bit" reproducible). she's consistent like that πŸ’…


🌸 CONFORMS TO 🌸

Debian policy, version 3.0.1


πŸ‘‘ SEE ALSO πŸ‘‘

This program is a part of debhelper.


🫢 AUTHOR 🫢

Joey Hess <joeyh@debian.org>


and that's the whole page, bestie!! go strip something responsibly πŸ’–

this was DH_STRIP(1) from debhelper version 14.5ubuntu1, dated 2026-09-21 β€” mwah, slay, byeee βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from