Re: Suggestion to ignore unused libs
Date: Fri, 13 Feb 2009 15:21:44 +0000
Daniel Johnson wrote:
> Libtool has an annoying habit of linking in indirectly linked
> libraries on some systems even when those libraries aren't being used.
> For example, on Mac OS X when I build libcurl with libidn, I also have
> to link in libintl, and therefore anything linking to libcurl also has
> to link to libintl. OS X doesn't actually require this for shared
> libraries, only static ones, but libtool plays it safe and does it
> anyway even if static libraries are disabled, which I usually do.
> Some linkers have a switch to automatically remove unused libs at link
> time. Gnu ld uses --as-needed, OS X uses -dead_strip_dylibs, and
> Solaris uses -z ignore. Those are the ones I know of. I've been adding
> -Wl,-dead_strip_dylibs to my OS X builds for a while now with no ill
> effects. But I was thinking that it might be good to have configure
> check for these flags and add them to LDFLAGS as appropriate. Gnulib
> actually has such a macro, gl_IGNORE_UNUSED_LIBRARIES, which I
> modified to check for -dead_strip_dylibs and am including below. The
> macro should be called before checking for c-ares since the
> AC_LINK_IFELSE will always fail if building the included ares because
> libcares doesn't exist yet.
You have to be careful removing "unused" shared libs, because
sometimes just loading them can have side-effects at run time which
That's quite unusual, but it is something expected in the behaviour of
Still, it's probably a libtool bug to be linking them on systems which
automatically follow shared library dependencies at run time, and an
appropriate bug report to the libtool developers would be appropriate.
Is Mac OS X a system where shared library dependencies are followed at
For example, if your program is linked to libidn and not libintl, and
libidn depends on functions in libintl, will the run time loader pull
in libintl even though it's not mentioned in your programs shared
library dependencies? Some systems do this and some don't, which is
why libtool is conservative (as with static libs), but it's
unnecessary on systems which do it at run time.
I say it's probably a libtool bug, however because of the side effects
of loading a shared lib at run time, at least the libtool behaviour
gives consistent run time behaviour between static and shared builds.
It's rarely what you wanted, though.
Received on 2009-02-13