Stuart Henderson wrote: > On 2021/12/12 12:10, Stefan Hagen wrote: > > 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. > > > > I thought so too. What about this? > > > But I think maybe we should just stop suggesting that completely (I > think it relates to a shortcut of just listing libraries for _all_ > subpackages in LIB_DEPENDS so they end up in every LIB_DEPENDS-subpkg > and relying on tools to prune the ones which aren't needed; in practice > afaik no port does that intentionally). > > Secondly "is safer" isn't really informative. Safer why? Unless it's > going to explain in more detail then something like "should be added" > would be better than "is safer". > > (also a nit: for manpages the standard is "new sentence -> new line").
I started to rewrite the paragraph and add more information about how dlopen is used and why rebuilds are necessary. But that made me think about how those reasons do not matter at all. We have libraries ports depend on. Ports should be updated when the library changes. No matter how the library is used. I think it's as simple as that. The problem is only that the ports system looks at dynamically linked libraries, which fails when the library is dlopened or statically linked in. Or maybe for stylistic reasons like setting LIB_DEPENDS globally and having flavors/subpackages that only need parts of it. It all boils down to: Libraries go to LIB_DEPENDS and WANTLIB. If you see this warning, check if the library is actually needed. If the answer is yes, ignore the warning and add a comment. Did I get this right? I reworked the paragraph a bit and dropped the multi-package case. Index: ./share/man/man5/bsd.port.mk.5 =================================================================== RCS file: /home/cvs/src/share/man/man5/bsd.port.mk.5,v retrieving revision 1.550 diff -u -p -u -p -r1.550 bsd.port.mk.5 --- ./share/man/man5/bsd.port.mk.5 22 Nov 2021 11:17:39 -0000 1.550 +++ ./share/man/man5/bsd.port.mk.5 12 Dec 2021 13:07:44 -0000 @@ -3558,17 +3558,16 @@ usage. .It 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. +This is often because of confusion between LIB_DEPENDS and RUN_DEPENDS. .Pp -Might be intentional sometimes, if some compile flavors create static binaries, -for instance. -Also, will happen for multi-packages, where one sets LIB_DEPENDS to have -a given build dependency (and corresponding WANTLIB for a given SUBPACKAGE). -.Pp -See -.Cm print-package-args Pq Cm lib-depends-args -for details. +Needed libraries should always be added to LIB_DEPENDS and WANTLIB. +In cases where the libraries are not dynamically linked in, +.Cm lib-depends-check +will raise a warning, because it can't detect the dependency. +For example for statically linked libraries, or libraries that are +loaded by +.Xr dlopen 3 . +In this case, add a comment to the Makefile about the intentional warning. .It "Warning: FULLPKGNAME-sub defined but not FULLPKGPATH-sub" .Ev FULLPKGNAME-sub has been explicitly defined by the port, instead of relying on the default,
