[ 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
