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. > > > > > For the port consumption, I believe that the better solution is to provide > > a pack of the .pc files describing base libraries, most likely as port. > > Yeah the port is another thing which yes can probably be done that way. > > > > > Using .pc for the base system build is overkill, it does not add anything > > that cannot be accomplished by our existing build system. IMO. > > Probably. > The thing is with pkgconf, fstat does not need to know that procstat > needs libkvm and libutil for static link, it just has to know it needs > procstat > and pkgconf does all the magic. and pkgconf is really small (only 48k on an > amd64 box) > > Other solution would be to reinvent the same thing using our framework? > Maybe a LDSADD (LD STATIC ADD) to differenciate both?
First, there is a linker flag, --as-needed, which does exactly what you want: it only registers the dso as a dependency using DT_NEEDED dynamic tag when there are real references from the linked object to the symbols in the dso. On the other hand, I am not a big fun of this feature. Dynamic linker is permissive for the main binary to reference a symbols in implicit dependencies of the explicit dependencies. If sudden change causes the main binary to start using a symbol from 'second order' dsos, you cause unneccessary complications there. More, recently there was a trend in the Linux world to disable the static linker from resolving symbols from the second order dsos. See the --no-add-needed and its recent switch in the newer ld. Overall, I like the fact that we explicitely list all depended base libraries in the link command, for the base system.
pgphsm2ISdNX9.pgp
Description: PGP signature
