Re: autoconf linking with shared object

[Ralf Wildenhues]

Hi Braden,

* Braden McDaniel wrote on Wed, Mar 29, 2006 at 10:32:37AM CEST:
> On Wed, 2006-03-29 at 10:02 +0200, Ralf Wildenhues wrote:
> 
> > You definitely want to put dependent libraries (those `-lfoolib' flags)
> > into one of the automake Makefile macros LIBS, someprogram_LDADD,
> > libsomelibrary_LIBADD, or similar, and not into *_LDFLAGS.
> 
> I hear this advice from time to time (and I have read what the autoconf
> and automake manuals have to say). Yet, as a practical matter, -l and -L
> flags frequently wind up as part of the same autoconf substitution in
> many build systems (e.g., such falls out of the typical usage pattern
> for pkg-config) and consequently get put into *_LDFLAGS as a unit. I do
> not think I have observed any bad effects from this to date.

That's very likely because you rarely do static linking.

> Is this advice really still relevant? Are all those packages that apply
> -l and -L together as a unit Doing It Wrong?

Yes.  And anybody trying to link completely statically in this case will
be hurt: the linker will only search the static libraries when it
encounters them on the command line; if a later library needs some
object from an earlier one pulled in (that wasn't already pulled in by
something else), then you will get a link failure.

And yes, static linking has become less prevalent, but I would not
consider it dead by any means: sometimes those small binaries generated
by linking statically against one of those libc implementations tuned
for size (uclibc, dietlibc) come in really handy, especially as tools
to fix an otherwise utterly broken system.  Yes, I've hosed my libc
before, on a package upgrade.

Sometimes some libraries are linked statically so that the resulting
binary may be carried from one GNU/Linux system to another.  But that's
more of an issue for non-free software packages that don't want to give
away the source.

And then there's the venerable old Cray without shared libraries.  :-)

Cheers,
Ralf