LIBRARY-SPECS(7)

NAME
library-specs - shared library name specifications

DESCRIPTION
Each WANTLIB item in the ports tree conforms to

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

or

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

All libraries that a package needs must be mentioned in that list. Except for system and X11 libraries, they all must be reachable through LIB_DEPENDS and RUN_DEPENDS, directly, or indirectly through recursive dependencies.

Conversely, the ports tree uses WANTLIB to check whether a given LIB_DEPENDS will be required at runtime for shared libraries, and thus turn it into a @depend line ( see pkg_create(1)).

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.

Note that static libraries can only satisfy a library specification if no shared library has been found. Thus, if WANTLIB = foo>=5, and both libfoo.so.4.0 and libfoo.a are present, the check will fail.

Therefore, porters must strive to respect correct shared library semantics in their own ports: by bumping the minor number each time the interface is augmented, and by bumping the major number each time the interface changes. Note that adding functions to a library is an interface augmentation. Removing functions is an interface change.

The major.minor components of the library specification are used only as a build-time check, the run-time checks are computed by resolve-lib(1). 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.

If a given architecture does not support shared libraries, all LIB_DEPENDS will be turned into simple BUILD_DEPENDS checks, and so, failure to mention RUN_DEPENDS if the port needs anything beyond libraries from the dependent port will lead to strange errors on such architectures.

Most specifications won't mention a path: resolve-lib(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 as they won't be reached directly.

However, 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.

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’.

SEE ALSO
check-lib-depends(1), ld(1), ld.so(1), pkg_add(1), resolve_lib(1), bsd.port.mk(5), packages(7), packages-specs(7), ports(7), ldconfig(8)

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.