On 2021/12/12 03:51, Anthony J. Bentley wrote: > Stuart Henderson writes: > > Please put them in LIB_DEPENDS/WANTLIB with the annotation in the comment. > > What they're doing is not safe/reliable because it relies on the library > > ABI not changing. Adding as a LIB_DEPENDS ensures that yquake is updated > > when required due to any incompatible changes to the libraries. > > This needs to be documented somewhere. bsd.port.mk(5) implies that > LIB_DEPENDS is not necessary for dlopen'd libraries: > > LIB_DEPENDS <spec> not needed for <FULLPKGPATH> There doesn't seem to be > any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't > turn into a @depends line in the created package. This is often because > of confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed > for dlopen'd libraries.
There are a few related subjects - software which dlopen's a shared library (.so.X.Y file) - software which links to a library statically - (and of course the standard case "software which links to a shared library") In all these cases, when the library is updated, packages depending on that library need to be considered for updates. In the "static linking" case, every time the library is changed, packages of the dependent port need to get updated to pick up changes (security fixes etc). Really the only reliable way we have to handle updates for static libraries is to bump REVISION on the static linked ports whenever the library is updated. Adding a "bogus" LIB_DEPENDS+WANTLIB will catch some updates but only if the library version of the associated shared library changes (i.e. on ABI changes) but often security fixes deliberately don't change ABI. "dlopen a shared library" is often used when software wants to use some library when possible but fallback to running but with lesser functionality if the library isn't present. I think this is the usual case within qt/kde ports for example. This is very similar to the standard case; usually the depending port does pull in headers from the library and if those headers change in an incompatible way (i.e. changes which would result in a libray version number change) the depending port needs to be rebuilt. Same as the standard case. The difference is that in the standard case, tools can find the library dependency automatically (check-lib-depends runs objdump -p and looks at NEEDED entries) whereas in the dlopen case you have to find them yourself. We can't handle "update automatically when the library changes in an incompatible way" unless an actual runtime dependency is listed. Listing as BUILD_DEPENDS and RUN_DEPENDS would mean that updates don't happen when needed. Listing as LIB_DEPENDS without a WANTLIB line (triggering the "not needed for" message) would mean that updates don't happen when needed _and_ it's only treated as a build dependency not a runtime dependency. So really the only way we can handle this is to list as LIB_DEPENDS and WANTLIB (forcing the runtime dependency) and comment to annotate that we should ignore check-lib-depends not being able to find a NEEDED line.
