Re: *_LDFLAGS vs. *_LDADD vs. *_LIBADD

[Ralf Wildenhues]

[ automake added; this is
  http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00141.html ]

Hello Bruno,

* Bruno Haible wrote on Mon, Sep 11, 2006 at 03:10:11PM CEST:
> Ralf Wildenhues wrote:
> > > And for executables, an *_LDADD variable exists, but the automake doc says
> > > the opposite of what you say:
> > > 
> > >    `PROG_LDADD' is inappropriate for passing program-specific linker
> > >    flags (except for `-l', `-L', `-dlopen' and `-dlpreopen').  So, use the
> > >    `PROG_LDFLAGS' variable for this purpose.
> > 
> > In what way is this opposite to my statement?  -l is listed as exception
> > in parentheses.
> 
> The options that I need to put there (from $(LTLIBICONV) or $(LIBICONV) etc.)
> can contain -L, -l, and -rpath / -Wl,-rpath options. The latter should not
> be added to PROG_LDADD, says the automake doc. So we must add them to
> PROG_LDFLAGS.

But this will simply not work for static compilation, as the *LDFLAGS
will appear on the command line before the object files.  So libiconv.a
or -liconv (or whatever else $(LIBICONV) expands to) will not be
searched for symbols that are needed from the objects (and not pulled
in for some other reason already).

> It's not only the lib-link.m4 macros which produce -L, -l, -rpath options
> together. pkgconfig descriptions (its 'Libs:' field) and xyz-config scripts
> do the same (at least for -L and -l). Therefore it is unrealistic to ask
> people to put the -L options into one variable and the -l options into
> another variable.

-L is explicitly excepted in the documentation as well, so the pkgconfig
Libs: description is not a problem.

So, to conclude, there are two points: I'm not sure why PROG_LDADD is
inappropriate for those other linker flags, and I'm not able to infer
that from the Automake manual, neither from the error message that
Automake gives.

But I do know that, if you want to static linking to work, you have no
choice but to provide libraries after the objects that need them.  Some
question being unrealistic to ask does not invalidate the issue that the
choice at hand breaks some usage (that I so far thought to be supported).

I should note that this case is only a problem when Libtool is not used:
libtool will reorder the command line so that `-l' flags appear after
all encountered objects.

Cheers,
Ralf