Re: libtool dependency issues

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Fri, Aug 24, 2018 at 10:17:14AM -0400, Greg Troxel wrote:
> 
> Joerg Sonnenberger <joerg%bec.de@localhost> writes:
> 
> > On Tue, Aug 21, 2018 at 12:04:40PM -0400, Greg Troxel wrote:
> >> However, when they use libtool to link, -lgeos gets added to the linker
> >> command line because /usr/pkg/lib/libgeos_c.la has
> >> 
> >>   dependency_libs='/usr/pkg/lib/libgeos.la'
> >
> > It has always done that as it is required for static linkage and various
> > other formats. More importantly, it has no chance to know whether or not
> > the symbols are used and broken modern elf linkers get very picky if you
> > don't specify all the libraries, even if the correct DT_NEEDED entries
> > exist.
> 
> Is the NetBSD dynamic linker broken in this way?  I had thought the
> point was that a library could have recorded that it needed other
> libraries, and dynamic linking to the first would ensure that the rest
> were loaded at runtime.

That's the ELF semantics. But the linkers (not the loader!) decided that
you still should have to specify all the libraries, even if they are
already in the namespace indirectly.

> So therefore, if there is a dependency_libs= for libbar in a foo
> package, then it is necessary for foo's bl3 to include libbar's bl3, and
> thus any package depending on foo will also depend on libbar?

Yes.

> And, does it mean that the geos notion of having a almost-never-changing
> C API and an often-changing C++ API mean that it only works for API
> compat, and that we indeed need to revbump all packages that depend on
> geos every time there is a C++ ABI change, even though the depending
> packages try to only use the C API?

We currently don't have a good way to express that or more importantly,
to not artifically revbump packages that are strictly indirectly exposed
to an ABI.

Joerg