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: pgpxuDm949pH3.pgp
Description: PGP signature

Reply via email to