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. Is the above not the right thing, or are you saying that so many linkers are troubled that libtool always uses this workaround? 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? 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?
Attachment:
signature.asc
Description: PGP signature