tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [PATCH] Transitive LIBDPLIBS, PROGDPLIBS



At Sat, 18 Jan 2025 23:04:30 +0100, Rhialto <rhialto%falu.nl@localhost> wrote:
Subject: Re: [PATCH] Transitive LIBDPLIBS, PROGDPLIBS
>
> On Wed 15 Jan 2025 at 10:32:29 -0800, Greg A. Woods wrote:
> > At Wed, 15 Jan 2025 08:19:14 +0000, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> > Subject: [PATCH] Transitive LIBDPLIBS, PROGDPLIBS
> > > (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.
>
> No I don't want to include transitive dependencies in the linker command
> line. If I use libfoo, its transitive dependencies are an implementation
> detail I don't want to need to bother with. They can change without
> notice, too.

I see your point, but I still don't agree that it is OK to ignore the
dependency at build (or install!) time.  In the role of software
configuration and security management I want the build-time linker, and
any installation tools, to know all about all dependencies, including
transitive dependencies, even if the latter might change or dissappear
with a minor (non-ABI) change in the implementation of a primary
dependency.

Part of the problem is due to what you point out next:

> I am still quietly hoping that some more tree-like namespace model comes
> in fashion. For example, if prog depends on libfoo depends on libbar,
> then only references from libfoo are allowed to be resolved by libbar.

Then it would indeed be OK to ignore a transitive dependency and to
treat it as an implementation detail.

I think to do that right, i.e. safely, would require something along the
lines of full "capabilities" support in the OS, perhaps even doing
runtime linking in "the kernel" (so to speak) allowing full hardware
memory protection for such transitive dependencies.  I'm not sure even
Multics could do that yet though (maybe, e.g. with some libraries in a
different ring).  Maybe it's in the realm of possibility for the Cheri
architecture.

--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgp63WLXYay1x.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index