{{{Also, on a related note, while preparing glotski for upload, I noticed that it was linking in unnecessary libraries by blindly passing the output of pkg-config libgnomeui-2.0 --libs to the linker. The resulting binary depended on a lot of libraries that it didn't actually use. Adding '-Wl,--as-needed' to the link line got rid of the unnecessary dependencies.}}}


{{{LDFLAGS="-Wl,-as-needed"

from: http://www.hanskalabs.net/ldflags-wl-asneeded/#more-106}}}


{{{removing unneeded lib on compilation:

> It spews several pages of dpkg-shlibdeps warnings during build -- what > about > trimming the libs somehow?

That's something I wanted to do, but I didn't find a good way to do that. I tried to replace ${shlibs:Depends} with only necessary library, but dpkg-shlibdeps still get the same warnings. I searched for a method with the new symbols system, but I found nothing about this (like a ${symbols:Depends} things).


Oh, no, you definitely don't want to touch that!

The idea is to get rid of extra/unneeded “-lfoo -lbar …” in the upstream Makefile, so as to link only against the libraries that are actually used.

Sometimes, just deleting an -lfoo would do. But more commonly, the build system doesn't allow you to use fine-grained library dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend, since it tells the linker to forget about the unused libraries (resulting in less NEEDED entries, and happy dpkg-shlibdeps).

*BUT* that might break the resulting binaries, since (depending on various things, like build/link options), you may end up with undefined references, which result in runtime crashes.

To avoid that, you probably want to use another LDFLAG(S): -Wl,-z,defs, which explicitely forbids such undefined references.

Note that this might still break the build system, but that *is* a good thing. Usually, the problem is that the intermediate builds are broken, since the resolution of undefined references is (again, in some conditions) postponed to the final linking. By using this option, you explicitely forbid any single undefined reference (including in the intermediate targets), which means that you might sometimes have to modify the Makefiles to add some -lfoo or -lbar, or e.g. add TARGET_LINK_LIBRARIES() in cmake build systems.

That's a bit of work, but you'll probably end up with less dependencies (expressed in less Depends:), which is obviously (installed size, testing migration, etc.) a good thing.


> Sometimes, just deleting an -lfoo would do. But more commonly, the > build system doesn't allow you to use fine-grained library > dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend, > since it tells the linker to forget about the unused libraries > (resulting in less NEEDED entries, and happy dpkg-shlibdeps). > > *BUT* that might break the resulting binaries, since (depending on > various things, like build/link options), you may end up with > undefined references, which result in runtime crashes.

I can only stress that the *but* here can be a blocker. Not all packages can get away with:

> To avoid that, you probably want to use another LDFLAG(S): > -Wl,-z,defs, which explicitely forbids such undefined references.

> Note that this might still break the build system, but that *is* a > good thing.

(Agreed, but is probably easier to fix upstream than in Debian, YMMV).

The main culprit here is Gtk+ (and probably Qt for similar reasons) and I need to find an overall solution to the problem for Emdebian. The problem is identifying *which* reports from dpkg-shlibdeps actually matter in the grand scheme of things. If a package causes an extra dependency that is a problem, yes, but if that extra dependency is genuinely necessary for some other application which would almost inevitably be installed alongside the package in question, then no harm is done.

I'm looking at storing the output of dpkg-shlibdeps in some form of database so that I can cross reference which dependencies might be completely unnecessary for a given selection of packages. It'll take some time and will have to fit in with my other work so if anyone fancies helping out . . . .

(It'll probably give me a good reason to investigate mole too.)

> That's a bit of work, but you'll probably end up with less > dependencies (expressed in less Depends:), which is obviously > (installed size, testing migration, etc.) a good thing.

Agreed, it is a v.good thing. Not sure it is yet something we should be advising on mentors, that's all. It may well be harder than expected and the methods are not that user-friendly.}}}