[sr #111217] "link_all_deplibs": issue with overlinking dependencies

--8323329-459834652-1743709737=:1941425
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/support/?111217>=0A=0A                 S=
ummary: "link_all_deplibs": issue with overlinking=0Adependencies=0A       =
            Group: GNU Libtool=0A               Submitter: None=0A         =
      Submitted: Thu 03 Apr 2025 07:48:53 PM UTC=0A                Category=
: None=0A                Priority: 5 - Normal=0A                Severity: 4=
 - Important=0A                  Status: None=0A                 Privacy: P=
ublic=0A             Assigned to: None=0A        Originator Email: anthony.=
[email protected]=0A             Open/Closed: Open=0A         Discussion Lock:=
 Any=0A        Operating System: *BSD=0A=0A=0A    _________________________=
______________________________=0A=0AFollow-up Comments:=0A=0A=0A-----------=
--------------------------------------------=0ADate: Thu 03 Apr 2025 07:48:=
53 PM UTC By: Anonymous=0AHi,=0A=0AI am facing an issue with dependency "ov=
erlinking" (related to the=0A"link_all_deplibs" variable).  This is on NetB=
SD, but it concerns all ELF=0Asystems. As far as I can tell, on NetBSD at l=
east, a libtool library is linked=0Awith all the dependencies of any depend=
ent libtool libray. Let's summarize it=0Awith an example.=0A=0AIn the follo=
wing scenario, imagine 3 libtool libraries X, Y and Z:=0A=0AlibX-1.la -> li=
bY-1.la -> libZ-1.la=0A=0Awhere libX (major version 1) depends on libY (maj=
or version 1) which depends=0Aon libZ (major version 1).=0A=0ALinking libX-=
1.la with libtool to libY-1.la (and just this one) will add the=0AlibZ-1.la=
 dependency to libX-1.la in the DSO file. This is useless on any ELF=0Asyst=
em, as libY already holds that dependency information thanks to the=0ADT_NE=
EDED tag. libX should only depend on libY, if that's what is given on the=
=0Acommand line.=0A=0AThis can even be wrong in the case where libZ is a pr=
ivate dependency of libY=0A(so that libZ is not part or libY ABI). If at so=
me point libY is upgraded to=0AlibY-1.1.la, now internally using libZ-2.la,=
 then libX-1.la with be dependent=0Aon both libZ.so.1 and libZ.so.2, which =
may not work at all.=0A=0AI noticed that this behaviour does not happen on =
a Debian system. So while=0Aanalyzing the differences between a Debian syst=
em and NetBSD, I found this=0Apatch from Debian:=0Ahttps://sources.debian.o=
rg/src/libtool/2.5.4-4/debian/patches/link_all_deplibs.patch/=0AThis is fro=
m the list of current patches to Debian libtool package:=0Ahttps://udd.debi=
an.org/patches.cgi?src=3Dlibtool&version=3D2.5.4-4=0A=0AThis patch addresse=
s exactly my issue (enven though it should be extended to=0Aany ELF system,=
 in particular NetBSD, and not only Linux).=0A=0ASo I was wondering if you =
where somehow aware of this patch (the Debian entry=0Asays "not submitted u=
pstream"), and if you think it makes sense. The comment=0Asays "will be fix=
ed in a better way in a future upstream version", hence my=0Aquestions.=0A=
=0AIn any case, I can work on a fix for NetBSD, if you think that's relevan=
t, but=0AI think the above patch should be considered.=0A=0ACheers,=0AAntho=
ny=0A=0A=0A=0A=0A=0A=0A=0A=0A    __________________________________________=
_____________=0A=0AReply to this item at:=0A=0A  <https://savannah.gnu.org/=
support/?111217>=0A=0A_______________________________________________=0AMes=
sage sent via Savannah=0Ahttps://savannah.gnu.org/=0A
--8323329-459834652-1743709737=:1941425
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCZ+7mKQAKCRCqLAuaBUf3
Tt5CAPsH0v/zC8SAUULXgAM+7G/BnVcKDOGEY4GBnxO8VyYnAwEA9AD2j31hPcJN
5eI+s76ulKsZflhgR3pHPD4ol+8WogA=
=B9DT
-----END PGP SIGNATURE-----

--8323329-459834652-1743709737=:1941425--