[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LT_* equivalent to AC_CHECK_LIB?

From: Ralf Wildenhues
Subject: Re: LT_* equivalent to AC_CHECK_LIB?
Date: Mon, 3 Jul 2006 23:18:39 +0200
User-agent: Mutt/1.5.11+cvs20060403

* Russ Allbery wrote on Mon, Jul 03, 2006 at 11:14:34PM CEST:
> Bob Friesenhahn <address@hidden> writes:
> > Operating systems with robust library dependency support don't like the
> > libraries explicitly specifying dependendies on libraries they are not
> > immediately dependent on.  Libtool has been specifying the full list of
> > dependencies to the linker, as it finds them in the .la files.
> And mostly because, unlike pkg-config, libtool doesn't distinguish between
> dependencies required for static linking and dependencies required for
> shared linking.

This is a common misconception.  Not all systems allow you to omit
indirect dependencies even for shared linking, AFAIK.

The issue really is direct vs. indirect dependencies, with static
linking not allowing indirect ones.

> > You may see that autoconf encourages configure scripts to supply all of
> > the library dependencies since the tests require it.
> Except in practice the tests don't on systems using shared libraries and
> shared linking with reasonable shared library dependency support (the
> default most places now).

Yes.  Every now and then you get a bug report from someone linking
statically.  Like users of dietlibc or another tiny libc.

> > Likewise, libtool applies all of the libraries it is instructed to apply
> > as well as additional dependencies obtained via the .la files.  A
> > smarter build system would allow libtool to distinguish between
> > immediate dependencies and "extraneous" dependencies and only apply the
> > immediate dependencies if the OS/linke support it.
> That would be very nice.  It does require input from the person building
> the library, though,


> or very recent GNU ld with options that don't work
> properly on some more obscure platforms.

That may not even be enough: You may _want_ to link against libfoo, even
if you don't use it, in order to have those symbols available when you
later dlopen some module.  (This isn't portable, but people still want
to be able to do this.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]