DH_MAKESHLIBS(1)

🌸 NAME 🌸

dh_makeshlibs β€” the bestie who automatically creates your shlibs file and calls dpkg-gensymbols for you. she handles the paperwork while you thrive, periodt. πŸ’…

✨ SYNOPSIS ✨

dh_makeshlibs [debhelper options] [-mmajor] [-V[dependencies]] [-n]
              [-Xitem] [-- params]

πŸ’– DESCRIPTION πŸ’–

okay so, listen. dh_makeshlibs is a debhelper program and its entire job is scanning for shared libraries and generating a shlibs file for the libraries it finds. that's the assignment, and it eats. πŸ“

it will also make sure that ldconfig gets invoked during install and removal when it finds shared libraries. since debhelper 9.20151004, that's done via a dpkg trigger. in older versions of debhelper, dh_makeshlibs would generate a maintainer script for that purpose instead β€” different era, babes. πŸ•°οΈ

since debhelper 12.3, dh_makeshlibs will by default add an additional udeb line for udebs in the shlibs file, when the udeb has the same name as the deb followed by a -udeb suffix β€” e.g. if the deb is called libfoo1, then debhelper will auto-detect the udeb if it is named libfoo1-udeb. when that auto-detection is insufficient, please use the --add-udeb and --no-add-udeb options below. they exist for exactly this. 🫢

⚠️ real talk warning: if you previously used --add-udeb and you're considering migrating to the new auto-detection feature in 12.3, then please remember to test that the resulting DEBIAN/shlibs files are as expected. there are some known corner cases where the auto-detection is insufficient. these include when the udeb contains library files from multiple regular deb packages, or when the packages do not follow the expected naming convention. iykyk β€” go test it. 😭

πŸŽ€ FILES πŸŽ€

  • debian/package.shlibs β€” installs this file, if present, into the package as DEBIAN/shlibs. if it's omitted, debhelper will generate a shlibs file automatically if it detects any libraries.
heads up bestie: in compat levels 9 and earlier, this file was installed by dh_installdeb(1) rather than dh_makeshlibs. yes, really. πŸ’€
  • debian/package.symbols, debian/package.symbols.arch β€” these symbols files, if present, are passed to dpkg-gensymbols(1) to be processed and installed. need different symbols files for different architectures? use the arch-specific names, that's literally what they're for. ✨

πŸ’… OPTIONS πŸ’…

  • -mmajor, --major=major β€” instead of trying to guess the major number of the library with objdump, use the major number you specified after the -m parameter. ngl this is much less useful than it used to be β€” back in the bad old days, this program looked at library filenames rather than using objdump. relic behaviour, iconic in a historical way. πŸ‘‘
  • -V, -Vdependencies, --version-info, --version-info=dependencies β€” if a shlibs file is generated by this program, this option controls what version will be used in the dependency relation.
    • in compat 12 and later, dh_makeshlibs defaults to -VUpstream-Version.
    • in compat 11 and earlier the default behaved like -VNone.

the dh_makeshlibs tool can generate dependencies in three variants. here they are, all three, no skips: 🌈

-VUpstream-Version

the dependency will be "packagename (>= packageversion)". note that Upstream-Version is case-sensitive and must be written exactly as shown here.

this is a conservative setting that always ensures that other packages' shared library dependencies are at least as tight as they need to be (unless the library is prone to changing ABI without updating the upstream version number).

the flip side is that packages might end up with dependencies that are too tight in some cases (note a symbols file can mitigate this issue). this is often of minor temporary inconvenience and usually a lot better than the fall out caused by forgetting to bump the dependency information.

this explicit form was added in debhelper/11.3. in previous versions, a -V without any dependency information was used instead (and that form still works). ✨

-VNone

the dependency will be "packagename". note that None is case-sensitive and must be written exactly as shown here.

this form is generally unsafe with the only exception being if upstream does not extend the ABI in any way. however, most upstreams improve their interfaces over time and packagers are recommended to use -VUpstream-Version (or one of the other forms of -Vdependencies).

alternatively, this may be sufficient if (and only if) the package uses symbol versioning (see dpkg-gensymbols(1)) and does not build any udeb packages. note that symbols are not supported for udeb packages, which solely relies on shlibs for dependency handling. 😭

-Vpackage-relation

in this case, the value passed to -V will be used as a dependency relation. the package-relation should generally be of the form "some-package-name (>= some-package-version)". remember to include the package name β€” fr fr, don't forget it. 🫢

note that debhelper will use the value as it is with no sanity checking or modification. in rare special cases, this is needed to generate a dependency on a different package than the one containing the library.

when choosing a value for this option, please keep mind that if the package provides a symbols file, then that this is generally preferred over the shlibs file for regular .deb packages. see dpkg-shlibdeps(1) for more information on this topic. πŸ’œ


  • -n, --no-scripts β€” do not add the "ldconfig" trigger even if it seems like the package might need it. the option is called --no-scripts for historical reasons, because dh_makeshlibs would previously generate maintainer scripts that called ldconfig. cute little fossil, we love a legacy name. πŸ¦‹
  • -Xitem, --exclude=item β€” exclude files that contain item anywhere in their filename or directory from being treated as shared libraries. bye bye, not you. πŸ™ˆ
  • --add-udeb=udeb β€” create an additional line for udebs in the shlibs file and use udeb as the package name for udebs to depend on instead of the regular library package.

this option is only useful for special cases such as when debhelper cannot auto-detect package name of the udeb package, when the udeb will contain libraries from multiple deb packages, or when the udeb contains libraries not present in the deb package. specialist behaviour, respect it. πŸ’…

  • --no-add-udeb β€” do not add any udeb lines to the shlibs file. this can be used to disable the default auto-detection of udebs.

this may be useful in case you do not want a shlibs file at all for the udeb because no package will depend on it. e.g. because adding a udeb package for the library was "overkill" and the library is embedded in a different udeb package. valid, honestly. πŸŽ€

  • -- params β€” pass params to dpkg-gensymbols(1). that's it. that's the whole option. 🫢

πŸ”₯ EXAMPLES πŸ”₯

  • dh_makeshlibs -VNone β€” assuming this is a package named libfoobar1, generates a shlibs file that looks something like:
libfoobar 1 libfoobar1
  • dh_makeshlibs -VUpstream-Version β€” assuming the current version of the package is 1.1-3, generates a shlibs file that looks something like:
libfoobar 1 libfoobar1 (>= 1.1)
  • dh_makeshlibs -V 'libfoobar1 (>= 1.0)' β€” generates a shlibs file that looks something like:
libfoobar 1 libfoobar1 (>= 1.0)

see? slay. three little shlibs, all exactly as you asked. ✨


πŸ¦‹ SEE ALSO πŸ¦‹

this program is a part of debhelper. πŸ’–


πŸ‘‘ AUTHOR πŸ‘‘

Joey Hess <joeyh@debian.org>


and that's the whole page bestie!! this was DH_MAKESHLIBS(1) from debhelper version 14.5ubuntu1, dated 2026-09-21. go generate some shlibs and be the main character of your own build. mwah. πŸ’–βœ¨πŸ’…

πŸ“¦ where this page comes from