[ http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/5122 ]
Hi Bruno, first off, thanks for the very nice and detailed report, and sorry for the delay. * Bruno Haible wrote on Sun, Dec 12, 2010 at 03:43:00PM CET: > When creating an executable or library, sometimes other libraries > have to be mentioned on the link command line as dependencies. [...] > When creating library.a, one can ignore dependencies to libraries not in the > build tree. So we need consider only maude, maudelt, and librarylt.la. > Where could I stuff the linker options or libtool options? > > - Can I put them in the *_LDFLAGS variable? > > No, it does not work, because if it's a static library > (/somewhere/libiconv.a), > the linker will not pick any object files from it, because it precedes > the *_OBJECTS on the link command line. Ralf noticed that in [2]. Agreed. > - Can I put them in the *_LDADD variable for programs or *_LIBADD variable > for libraries? > No, because the options contain other things than -l and -L options, and > these can't go in *_LDADD or *_LIBADD variables, says the Automake doc. > [3][4][5] Here, I think we need to adjust both the documentation and the implementation. Even with portability as important aspect, autotools should strive to support position-dependent linker flags better. -Wl,-Bstatic and several others come to mind. Of course supporting this right will also require changes to libtool, but that is a next step. > I understand that the true reason for this requirement is that Automake > wants to compute a *_DEPENDENCIES variable from *_LDADD or *_LIBADD > variables: > "If `PROG_DEPENDENCIES' is not supplied, it is computed by Automake. [...] Yes, I think that is the reason. We can still do so however even with more laxness, automake just has to skip the other flags. And we are limited in that at automake time, @substitutions@ cannot be analyzed anyway. > Additionally, for libraries, the description of LIBADD is strict > about the fact that it "should be used to list extra libtool objects > (.lo files) or libtool libraries (.la) to add to library." > > - Can I put them in LIBS? > > No, I explained above why I don't want this. Agreed. > Please offer a simple way to use these linker options. > > I can see two choices: > > A) Either allow -Wl,-rpath or -rpath options also in *_LDADD variables, > and allow -Wl,-rpath, -rpath, -l, -L options also in *_LIBADD variables > of libraries built with libtool. > > B) Or introduce a new set of variables *_LIBS that can contain link options > for dependencies, like $(LIBICONV) and $(LTLIBICONV) above. Modify the > link commands to look like this: > > For maude: > $(CCLD) $(maude_CFLAGS) $(CFLAGS) \ > $(maude_LDFLAGS) $(LDFLAGS) \ > -o $@ \ > $(maude_OBJECTS) \ > $(maude_LDADD) $(maude_LIBS) $(LIBS) > > For maudelt: > $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) > --mode=link \ > $(CCLD) $(maudelt_CFLAGS) $(CFLAGS) \ > $(maudelt_LDFLAGS) $(LDFLAGS) \ > -o $@ \ > $(maudelt_OBJECTS) \ > $(maudelt_LDADD) $(maudelt_LIBS) $(LIBS) > > For librarylt.la: > $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) > --mode=link \ > $(CCLD) $(librarylt_la_CFLAGS) $(CFLAGS) \ > $(librarylt_la_LDFLAGS) $(LDFLAGS) \ > -o $@ \ > -rpath $(libdir) \ > $(librarylt_la_OBJECTS) \ > $(librarylt_la_LIBADD) $(librarylt_la_LIBS) $(LIBS) > > Note that solution A) would have the drawback of an inconsistency between > library_a_LIBADD and librarylt_la_LIBADD: library_a_LIBADD must not contain > link dependencies (see [6]). Here's a third proposal: implement both (A) and (B), but in the latter let $(prog_LIBS) override $(LIBS) instead of having both. This would be consistent in how prog_LDFLAGS and prog_LDADD work, and you could still easily link with LIBS by using prog_LIBS = -lspecial $(LIBS) This idea is listed in the TODO file, too. Do you see any problem with the proposal? Thanks, Ralf
