Re: Re: [PATCH] Transitive LIBDPLIBS, PROGDPLIBS

> Date: Wed, 15 Jan 2025 10:32:29 -0800
> From: "Greg A. Woods" <[email protected]>
> 
> > (b) the necessary -l arguments are passed through (just -lsqlite3 for
> >     dynamic builds; -lsqlite3 -lm for static builds); and
> 
> This part I've never understood.  Why is there reluctance to require
> '-lm' for dynamic builds?  These small efficiencies lead to confusion
> and ignorance, as is evident in how much of a mess X11 linking is for
> many third-party programs.

We could also pass -lm under the hood for dynamic builds, but it
doesn't make a difference unless we are also talking about widening
the scope of this change to cover the linker and loader toolchain too,
so to keep the scope narrow I didn't consider making that change.

As for whether the Makefile should have to synatically mention libm to
pull in libsqlite3, it is important to set the direct dependencies
apart from the transitive dependencies so that if, say, libgssapi ever
_dropped_ a dependency on libsqlite3 (which it did!  PR lib/57406,
https://mail-index.netbsd.org/source-changes/2023/10/11/msg148056.html),
then you wouldn't have to wonder for every user of libgssapi whether
they really still need libsqlite3 (and libm) themselves or it was only
pulled in as a transitive dependency.

> If a dependent library grows a new transitive dependency on another
> library then I think this should always be treated as an ABI change and
> require recompilation (or at least re-linking), i.e. a major-number
> bump.

We could add a mechanism like the current .expsym lists to break the
build if the transitive closure of library dependencies changes.  We
could use a similar mechanism to trip on dependencies' shlib major
bumps.  That information could be carried through the same .deps.mk
files that this patch introduces, as future work.

For now, you can at least _discover_ the transitive dependencies
automatically through `make -v _LIBDPLIBS' or `make -v _PROGDPLIBS'
with this patch.