On Feb 13, 2009, at 10:21 AM, Jamie Lokier wrote:

> 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
> are wanted.
>
> That's quite unusual, but it is something expected in the behaviour of
> shared libs.

This is true, but libcurl doesn't do anything unusual that could cause
such a problem.

>
>
> 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
> run time?
>
> 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.

Yes, the dynamic loader handles this automatically for shared
libraries, so libcurl only has to link to libidn and not libintl. Each
library and executable contains the full path of every library linked
to and which symbol comes from which library, so the loader can just
follow the chain. When linking to static libs, however, all indirect
libs must be linked to. Static libs are the red-headed stepchildren of
OS X. They're not well supported and in fact it's impossible to make a
truly static binary so there's not much point in using them. I always
use --disable-static when I'm building libs.

Libtool is being conservative to deal with static libs.
>
>
> 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.

Yeah, I've talked to a libtool dev and he agreed that it was
suboptimal behavior, but didn't think it would change anytime soon.
Libtool doesn't really have a way to specify different dependency_libs
for dynamic and static libs. Adding the -dead_strip_dylibs flag only
affects shared libs though, and won't break static libs. The libs
still get passed on the link line, but the dynamic linker won't
actually link them if they're unused. The static linker is unaffected.

Daniel
Received on 2009-02-13