LIBRARY-SPECS(7)

📦 in nixpkgs unstable

💅 LIBRARY-SPECS(7) — shared library name specifications 🫶

okay so real talk, bestie: this is a page from the Miscellaneous Information Manual and it's literally all about how the ports tree writes down library names. iykyk. let's get into it ✨

🌸 NAME 🌸

library-specs — the shared library name specifications, aka the group chat rules for how we write library requirements 💖

🎀 DESCRIPTION 🎀

so every single WANTLIB item in the ports tree has to conform to one of these two shapes, no exceptions:

[path/]libname[=major[.minor]]

or

[path/]libname[>=major[.minor]]

All the libraries a package needs must show up in that list — like, every last one, periodt. The only exceptions are system libraries and X11 libraries. Everything else has to be reachable through LIB_DEPENDS and RUN_DEPENDS — either directly, or indirectly through recursive dependencies. chain of besties, basically 🫶

Conversely (iconic word), the ports tree uses WANTLIB to check whether a given LIB_DEPENDS will actually be required at runtime for shared libraries, and thus turn it into a @depend line — see pkg_create(1) if you wanna peek 👀.

The package system will embed correct dependency checks in the built package in the form of @wantlib lines, according to the normal shared library semantics: any library with the same major number, and a greater or equal minor number, will do. lowkey elegant tbh ✨

💀 careful, bestie: static libraries can only satisfy a library specification if no shared library has been found. So if WANTLIB = foo>=5, and both libfoo.so.4.0 and libfoo.a are present, the check will fail. not me finding out the hard way 😭

So, porters must strive to respect correct shared library semantics in their own ports — like, truly try:

  • bump the minor number each time the interface is augmented 🎀
  • bump the major number each time the interface changes 💅

And just so we're clear: adding functions to a library is an interface augmentation. Removing functions is an interface change. no cap.

🌈 the major.minor deets

The major.minor components of the library specification are used only as a build-time check — the run-time checks are computed by port-resolve-lib-helper(1). main character energy fr fr 👑

  • for libname>=major[.minor], any library which is more recent than the given major.minor version will do ✅
  • if a specific major number is needed, use the form libname=major[.minor] 🎯
  • if the minor component is left empty, any minor will do
  • if both components are left empty, any version will do 🌸

🦋 about paths

Most specifications won't mention a path: port-resolve-lib-helper(1) will look in the default ldconfig(8) path automatically, namely:

  • /usr/local/lib
  • /usr/X11R6/lib
  • /usr/lib

It is generally a bad idea to put libraries elsewhere, because they won't be reached directly. 🙈

However — and this is the fun part — distinct ports may install different major versions of the same library in /usr/local/lib, and disambiguate the build by creating a link in a separate directory, and specifying the right options to the linker. big brain move 🧠✨

These libraries will require a path component in the corresponding WANTLIB to make sure the right library is resolved. This path is rooted under /usr/local. For instance, to refer to /usr/local/lib/qt3/libqt-mt.so.33.0, one would use lib/qt3/qt-mt>=33. slay 💅

⭐ SEE ALSO ⭐

👑 HISTORY 👑

Full support for library specifications first appeared in OpenBSD 3.1. 🎉

The format of specifications changed slightly to include >= before OpenBSD 4.0.

The interactions between LIB_DEPENDS and WANTLIB were modified and clarified for OpenBSD 4.8.

The format of specifications changed again before OpenBSD 4.9 to remove extra noise. glow-up, honestly 🌟

🍓 and that's the whole page, bestie! this edition of LIBRARY-SPECS(7) is a Debian joint, dated July 9, 2018 — mwah, thanks for reading, ily, go bump those minor numbers 💖🧚‍♀️🌸
📦 where this page comes from