Date: Sun, 16 Dec 2012 16:03:40 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@freebsd.org>, hackers@freebsd.org Subject: Re: Fix overlinking in base aka import pkgconf Message-ID: <20121216140340.GY71906@kib.kiev.ua> In-Reply-To: <20121216130100.GD15112@felucia.tataz.chchile.org> References: <20121214235418.GF18884@ithaqua.etoilebsd.net> <20121215012233.GP71906@kib.kiev.ua> <20121215105643.GG18884@ithaqua.etoilebsd.net> <20121216130100.GD15112@felucia.tataz.chchile.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Sun, Dec 16, 2012 at 02:01:00PM +0100, Jeremie Le Hen wrote: > Hi bapt, kib, > > On Sat, Dec 15, 2012 at 11:56:43AM +0100, Baptiste Daroussin wrote: > > On Sat, Dec 15, 2012 at 03:22:34AM +0200, Konstantin Belousov wrote: > > > On Sat, Dec 15, 2012 at 12:54:19AM +0100, Baptiste Daroussin wrote: > > > > Hi, > > > > > > > > Some of our binary are overlinked, the way we handle the linking doesn't help > > > > for that. > > > What do you mean there ? Do you mean that some libraries specified for the > > > linking stage of the final binary are not needed for the execution ? > > > > I mean some library are registrer in the binary with DT_NEEDED tag where they > > don't need to. > > > > > > > > > > > > > On proposition could be to use pkgconf https://github.com/pkgconf/pkgconf which > > > > is BSD license pkg-config implementation 100% compatible with pkg-config. > > > > > > > > What I propose is to create a new PCADD variable for the Makefiles. > > > > > > > > PCADD will invoke pkgconf to gather the libraries and the cflags for a given > > > > project. > > > > > > > > The second thing would be to create .pc files for all of our libraries. > > > > > > > > for example: > > > > usr.bin/fstat dynamic build is overlinked > > > And how this is better than just removing the unneeded library from > > > the Makefile ? > > > > In that case to statically build you need -lkvm -lutil -lprocstat but if you > > build dynamically you will only need -lproctast meaning you don't need to be > > directly linked to libutil and libkvm. This means a breakage of libutil will > > only have inpact on procstat and no more on fstat for example. > > I think this could be solved by an implicit linker script contained in > .so and .a files, pointing to the real libraries. > > We have already the SHLIB_LDSCRIPT variable to accomplish this for .so > files. It may be possible to do the same for .a files, though this > would require renaming the real archives to something like .a.0 (here > I'm just taking a similar scheme to the one used for DSO). > > As a matter of fact, libprocstat.a would contain: > > GROUP ( /usr/lib/libprocstat.a.0 /usr/lib/libkvm.a /usr/lib/libutil.a ) > > Note that libkvm.a and libutil.a could be linker scripts as well. > > Kib, do you see any problem to this proposition? Wouldn't you need to completely rewrite the handling of the .a files in the share/mk ? I somewhat dislike the mere thought that .a is not an archive any longer. Does it make sense from the overhead and complexity POV, for such small goal ? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQzdS7AAoJEJDCuSvBvK1BHAkP/ir7TtycOje8jd5SSdEB2T3g ZGX9AS7xhwdG70z99KNL1kjuF26XNuQg7lJlpGb0+BUU2kt84pMq1ui5zUO7TlT/ 1st2hQoovRPjiss245j3f0iFIdRvqlvIAWTJrhi+a8V5ni+7NsgFGQoDiSLSgNdE PLwetkHCulyyu4v690lFmtlv83lUvko8HJ5x2PFBIp5jFf2vcKAiP2E22pUJD9bK sEKtKAwBm541IdqyvzFFlzxr3vdZgjCXEs69TLgyIL3FyvsBnkArQYlMG0DLonc1 Sya/px2p1iLuWMQCDpaRJlsJQ6NCxfTP8NltMmh3Q0BxDOa2Xh9c98gQGq2wIPv4 e53DcC9lOu4rE2WfEsdYUXl/Zrual8sMg5+IM3akJgBFoAOta9YOqIHKR2KKzCVF nqbTGtk9db+TU2e0dnzmQ6nP12qtHJqvrqaTG125pKtZS4DFjlIuL+PjlY3l0glb VCz+M5bM77QOIfghu8efy4fl5ooldA+PV2QyvoctQ9p7oDXwpWHWhY4HI9mdaXyS 9YOCmpCZhcvMnkuOlUzK+eAy82wpCWZKnq2cofBqv0yg+QShCYUJ0rXV7BxkUHJM C3042mhDAD+GLXzWV0K9LiguAnkRzdwsiTVxhaX8RyUVy2hot6v6U8aujF53fJN1 fTYwulHNb8pnCOilj69h =4LpY -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121216140340.GY71906>