From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 12 09:37:07 2010 Received: (at submit) by debbugs.gnu.org; 12 Dec 2010 14:37:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRn2w-0001SV-ID for submit@debbugs.gnu.org; Sun, 12 Dec 2010 09:37:07 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PRn2t-0001S1-CN for submit@debbugs.gnu.org; Sun, 12 Dec 2010 09:37:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRn8o-0008Tm-KU for submit@debbugs.gnu.org; Sun, 12 Dec 2010 09:43:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:42698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRn8o-0008Te-Gl for submit@debbugs.gnu.org; Sun, 12 Dec 2010 09:43:10 -0500 Received: from [140.186.70.92] (port=60458 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRn8m-0001DO-LS for bug-automake@gnu.org; Sun, 12 Dec 2010 09:43:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRn8k-0008Sz-20 for bug-automake@gnu.org; Sun, 12 Dec 2010 09:43:08 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.161]:65411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRn8j-0008Sa-7W for bug-automake@gnu.org; Sun, 12 Dec 2010 09:43:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1292164983; l=8319; s=domk; d=haible.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Subject:To: From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Qwt+YVB4ASihc8f2ZXKVpDrExDM=; b=F5SGoHWj2/koBYAO0Z6ZCUBHcSU2azUAWhhzuCtVpi3BgBW7+bbWm05rAusY6ovTA4u rK1nh9zp5zA8QDmJwBCvzIGxKa3uJwp8rczgHyTfx2ZpB8kraKY0wEqcjpE5hHVG3iLth w6Tc1CjyMvGZQZmipZHaiyZRZfspeW5oOyk= X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRbfA44+iwyQ== X-RZG-CLASS-ID: mo00 Received: from linuix.haible.de (dslb-088-068-046-137.pools.arcor-ip.net [88.68.46.137]) by post.strato.de (jimi mo49) (RZmta 24.8) with ESMTP id Y05c38mBCAq2zH ; Sun, 12 Dec 2010 15:43:02 +0100 (MET) From: Bruno Haible To: bug-automake@gnu.org Subject: add a way to pass link dependencies Date: Sun, 12 Dec 2010 15:43:00 +0100 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201012121543.01508.bruno@clisp.org> X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.6 (-----) Hi, When creating an executable or library, sometimes other libraries have to be mentioned on the link command line as dependencies. For dependencies inside the build tree, Automake handles this fine, through the _LDADD variable for executables and the _LIBADD variable for libraries. See e.g. the node "Linking" in the Automake manual. But for dependencies on libraries installed on the system, Automake does not provide a way to specify these link dependencies in a complete, reliable, and simple way. Please consider adding support for this to a future version of Automake. Let's take an example: You want to link with the libiconv library, which may be installed in /usr/lib, in /usr/local/lib, in /opt/gnu/lib, or similar. GNU gettext has a macro AM_ICONV which finds the library and defines Autoconf variables LIBICONV (for use without libtool) and LTLIBICONV (for use with libtool) that contain the needed linker options or libtool options, respectively. Similarly for other libraries. The problem is that is no way to use these with Automake in a reliable and simple way. Let me clarify the requirements: 1) I want to use the value of LIBICONV or LTLIBICONV. Typical values of LIBICONV are -liconv -Wl,-rpath,/usr/local/lib -L/usr/local/lib -liconv /usr/local/lib/libiconv.a -Wl,-rpath,/usr/local/lib /usr/local/lib/libiconv.so Typical values of LTLIBICONV are -liconv -rpath /usr/local/lib -L/usr/local/lib -liconv /usr/local/lib/libiconv.a -rpath /usr/local/lib /usr/local/lib/libiconv.so /usr/local/lib/libiconv.la In particular, I can't get away without -rpath options, otherwise the created programs just won't run. 2) Linking with a static library should work in the same way as linking with a shared library. 3) I want to be able to specify the link dependencies for every program and library separately. I don't want to put them into $(LIBS), because dependencies on unused shared libraries increase the startup time for programs, and the --as-needed option of the GNU linker is not portable and carries its own set of problems.[1] 4) I want to use the Automake-provided rules for linking. I don't want to override them, because that would be a maintenance hassle as Automake evolves. Now in which Automake provided variable could I stuff these linker options or libtool options? How to reproduce: In a package that already has a configure.ac that uses Automake but not Libtool, do "mkdir foo" and save this text as foo/Makefile.am: =============================== foo/Makefile.am ======================== bin_PROGRAMS = maude lib_LIBRARIES = library.a maude_CFLAGS = $(AM_CFLAGS) maude_LDFLAGS = $(AM_LDFLAGS) maude_LDADD = $(LDADD) #library_a_CFLAGS = $(AM_CFLAGS) # not used in linking #library_a_LDFLAGS = $(AM_LDFLAGS) # yields warning library_a_LIBADD = ======================================================================== then do "automake foo/Makefile" and look at the generated Makefile.in file. In a package that already has a configure.ac that uses Automake and Libtool, do "mkdir foolt" and save this text as foolt/Makefile.am: ============================== foolt/Makefile.am ======================= bin_PROGRAMS = maudelt lib_LTLIBRARIES = librarylt.la maudelt_CFLAGS = $(AM_CFLAGS) maudelt_LDFLAGS = $(AM_LDFLAGS) maudelt_LDADD = $(LDADD) librarylt_la_CFLAGS = $(AM_CFLAGS) librarylt_la_LDFLAGS = $(AM_LDFLAGS) librarylt_la_LIBADD = ======================================================================== then do "automake foolt/Makefile" and look at the generated Makefile.in file. The generated link commands are (with expanded *_LINK and *_AR variables): For maude: $(CCLD) $(maude_CFLAGS) $(CFLAGS) \ $(maude_LDFLAGS) $(LDFLAGS) \ -o $@ \ $(maude_OBJECTS) \ $(maude_LDADD) $(LIBS) For library.a: $(AR) $(ARFLAGS) library.a $(library_a_OBJECTS) $(library_a_LIBADD) $(RANLIB) library.a 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) $(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) $(LIBS) 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]. - 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] 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. The automatically-assigned value is the contents of `PROG_LDADD', with most configure substitutions, `-l', `-L', `-dlopen' and `-dlpreopen' options removed. The configure substitutions that are left in are only `$(LIBOBJS)' and `$(ALLOCA)'; these are left because it is known that they will not cause an invalid value for `PROG_DEPENDENCIES' to be generated. "If `_DEPENDENCIES' is not supplied, it is computed by Automake. The automatically-assigned value is the contents of `_LDADD' or `_LIBADD', with most configure substitutions, `-l', `-L', `-dlopen' and `-dlpreopen' options removed. The configure substitutions that are left in are only `$(LIBOBJS)' and `$(ALLOCA)'; these are left because it is known that they will not cause an invalid value for `_DEPENDENCIES' to be generated." 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. 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]). Bruno [1] http://www.gentoo.org/proj/en/qa/asneeded.xml [2] http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00146.html [3] http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00141.html [4] http://www.gnu.org/software/automake/manual/html_node/Linking.html [5] http://www.gnu.org/software/automake/manual/html_node/A-Library.html [6] http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00054.html From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 22 04:19:37 2011 Received: (at 7621) by debbugs.gnu.org; 22 Jan 2011 09:19:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PgZdA-0001wn-MA for submit@debbugs.gnu.org; Sat, 22 Jan 2011 04:19:37 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PgZd7-0001wa-Dn for 7621@debbugs.gnu.org; Sat, 22 Jan 2011 04:19:34 -0500 Received: (qmail invoked by alias); 22 Jan 2011 09:27:28 -0000 Received: from xdsl-89-0-146-100.netcologne.de (EHLO localhost.localdomain) [89.0.146.100] by mail.gmx.net (mp069) with SMTP; 22 Jan 2011 10:27:28 +0100 X-Authenticated: #13673931 X-Provags-ID: V01U2FsdGVkX18t2BMa32Yt6KL3oRasjd2qSkp6Xe9BE2A0DvHoD4 M233Sy+Z+/sQt4 Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1PgZkl-0000CH-Qj; Sat, 22 Jan 2011 10:27:27 +0100 Date: Sat, 22 Jan 2011 10:27:27 +0100 From: Ralf Wildenhues To: Bruno Haible Subject: Re: bug#7621: add a way to pass link dependencies Message-ID: <20110122092727.GE31878@gmx.de> References: <201012121543.01508.bruno@clisp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201012121543.01508.bruno@clisp.org> Organization: Institute for Numerical Simulation, University of Bonn User-Agent: Mutt/1.5.20 (2010-08-04) X-Y-GMX-Trusted: 0 X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 7621 Cc: 7621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.8 (--) [ 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 22 07:08:24 2011 Received: (at 7621) by debbugs.gnu.org; 22 Jan 2011 12:08:24 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PgcGV-0005bp-R9 for submit@debbugs.gnu.org; Sat, 22 Jan 2011 07:08:24 -0500 Received: from mo-p00-ob.rzone.de ([81.169.146.161]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PgcGS-0005bb-KU for 7621@debbugs.gnu.org; Sat, 22 Jan 2011 07:08:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1295698575; l=5112; s=domk; d=haible.de; h=Content-Transfer-Encoding:Content-Type:MIME-Version:In-Reply-To: References:Cc:Date:Subject:To:From:X-RZG-CLASS-ID:X-RZG-AUTH; bh=qo0eUes8iKGBydCszX5EVLRQm/I=; b=mwTbh+QvR7+b/XFVwcjRjPugOtCDUY1G8kVixH95Sj2MYJW5zo1BRwganbqlOrlkcZD xvagp2fOPZ5dw6ZO0LhOLaMCs7Psh150tv5+bH8p3BeaTq7N6G+YZcKLEpm+zLsMjKvvQ wZ990xSCZwbgGypYHHe5CCNOq/xGnX7yqjc= X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRbfA44+iwyQ== X-RZG-CLASS-ID: mo00 Received: from linuix.haible.de (dslb-088-068-046-137.pools.arcor-ip.net [88.68.46.137]) by post.strato.de (mrclete mo37) (RZmta 24.12) with ESMTP id 4059b5n0M8aOqc ; Sat, 22 Jan 2011 13:16:15 +0100 (MET) From: Bruno Haible To: Ralf Wildenhues Subject: Re: bug#7621: add a way to pass link dependencies Date: Sat, 22 Jan 2011 13:16:14 +0100 User-Agent: KMail/1.9.9 References: <201012121543.01508.bruno@clisp.org> <20110122092727.GE31878@gmx.de> In-Reply-To: <20110122092727.GE31878@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201101221316.14882.bruno@clisp.org> X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 7621 Cc: 7621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.6 (---) Hello Ralf, Thank you for taking care of this long-standing problem. > implement both (A) and (B), but in the latter > let $(prog_LIBS) override $(LIBS) instead of having both. For (A), the list of options to be ignored during dependency extraction is the following (cf. gnulib/build-aux/config.rpath): -rpath /some/path -Wl,-rpath -Wl,/some/path -Wl,-rpath,/some/path -lopt=-rpath -lopt=/some/path -Qoption ld -rpath -Qoption ld /some/path -R/some/path -R /some/path -blibpath:/some/path -Wl,-blibpath:/some/path +b /some/path -Wl,+b -Wl,/some/path A) Allow the above listed -rpath options also in *_LDADD variables, and allow the above listed -rpath options and -l, -L options also in *_LIBADD variables of libraries built with libtool. B) Introduce a new set of variables *_LIBS that can contain link options for dependencies, like $(LIBICONV) and $(LTLIBICONV) above. Let them default to $(LIBS). Modify the link commands to look like this: For maude: $(CCLD) $(maude_CFLAGS) $(CFLAGS) \ $(maude_LDFLAGS) $(LDFLAGS) \ -o $@ \ $(maude_OBJECTS) \ $(maude_LDADD) $(maude_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) 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) For the user, the benefit of using the *_LDADD and *_LIBADD variables will be that he does not make a distinction between already installed libraries and libraries in the build tree. But he has to be careful not to augment the *_LIBADD variable of a .a library. Whereas his benefit of using the *_LIBS variables will be that he can treat programs, .a libraries, and .la libraries the same way. But he has to be careful to handle dependencies to libraries in the build tree differently than dependencies to already installed libraries. The documentation could point this out. But if you ask me, it is suboptimal to offer to the user two different ways of doing the same thing, each with a different drawback. Ideally, there should be one way of doing it, with none of the drawbacks. So what I propose is C) Introduce a new set of variables *_LIBS like in (B), and use them (in the case of a program or .la library) for the construction of the *_DEPENDENCIES variable. This computation of the *_DEPENDENCIES variable would then need to be enhanced to ignore all kinds of linker options and pick only the tokens that end in ".a" or ".la". This will be needed because people can write conditional code like if USING_GNU_LD maude_LIBS += -Wl,-E endif if ON_WIN32 maude_LIBS += -Wl,--disable-auto-import endif if USE_EMBEDDED_LIBFOO maude_LIBS += ../foo/libfoo.a endif The documentation would make it clear that all link dependencies go in *_LIBS, for all kinds of programs and libraries. As a consequence, deprecate *_LDADD. But wait, deprecating *_LDADD and letting *_LIBS take over their role is a bit harsh. Why not keep the simplicity of proposal (C) without the deprecation? D) Introduce a new set of variables *_LDADD for libraries that are built with libtool. Don't touch LIBS. Modify the link commands to look like this: For maude: $(CCLD) $(maude_CFLAGS) $(CFLAGS) \ $(maude_LDFLAGS) $(LDFLAGS) \ -o $@ \ $(maude_OBJECTS) \ $(maude_LDADD) $(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) $(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_LDADD) $(LIBS) Compute the *_DEPENDENCIES not only from *_LDADD, but also from LIBS, ignoring all linker options like in proposal (C) above. The documentation would make it clear that all link dependencies go in *_LDADD and LIBS, for all kinds of programs and libraries, that LIBS is common to all programs and libraries being built by the same Makefile, and that the contents of *_LDADD and of LIBS are treated the same way. For libraries (both .la and .a libraries), the doc would continue to state that extra contents of the library goes in *_LIBADD whereas link dependencies go in *_LDADD (the latter being ignored for .a libraries, of course). I think this proposal does not have any of the drawbacks, provides a simple rule that the developer can easily remember, and is a straightforward extension of what Automake offers now. Bruno From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 22 15:44:15 2011 Received: (at 7621) by debbugs.gnu.org; 22 Jan 2011 20:44:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PgkJj-0004YY-5A for submit@debbugs.gnu.org; Sat, 22 Jan 2011 15:44:15 -0500 Received: from mail-qy0-f172.google.com ([209.85.216.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PgkJh-0004YN-Ps for 7621@debbugs.gnu.org; Sat, 22 Jan 2011 15:44:14 -0500 Received: by qyk34 with SMTP id 34so1637065qyk.3 for <7621@debbugs.gnu.org>; Sat, 22 Jan 2011 12:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bOWa5SStpgaYcqu120i4G/veEeUbYeuC+j/JGULwzQ8=; b=kb3JWVCY1EVl8NQHPV7e8wb/qm4KfarIPFlHQ8wOghExvS9Kj5uzrwo6oh69ksw3uQ q8hn0o8wQowYz/Htaz3DGjNLqlF8ZDrEAFic/T8JwvnDFP+Fw3Sc0BhuP708nqH1aVZF qCRrztjGagIu70Qg2TnqBy7cs0x00s62KMq4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RxOj9asVTaN/0yeDLpWBdWalij2LhVxiEMyiz20FcU8QQMvyi0UFrPxUBfpQffrrhY jktj1bHylQ0Qt1a/fiUOzCFhvpm0wtg9HlCH94OA/6iilSDBlcdSzGbPsfqFtHuxJju9 l897vGjc1YWNdhE8VYmLBW9zlmh3dsYxak9FM= MIME-Version: 1.0 Received: by 10.229.219.136 with SMTP id hu8mr2063881qcb.249.1295729530258; Sat, 22 Jan 2011 12:52:10 -0800 (PST) Received: by 10.220.188.136 with HTTP; Sat, 22 Jan 2011 12:52:10 -0800 (PST) In-Reply-To: <201101221316.14882.bruno@clisp.org> References: <201012121543.01508.bruno@clisp.org> <20110122092727.GE31878@gmx.de> <201101221316.14882.bruno@clisp.org> Date: Sun, 23 Jan 2011 07:52:10 +1100 X-Google-Sender-Auth: R79JSrINPrgJDaixvncJHIdz0e4 Message-ID: Subject: Re: bug#7621: add a way to pass link dependencies From: Jack Kelly To: Bruno Haible Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.9 (---) X-Debbugs-Envelope-To: 7621 Cc: Ralf Wildenhues , 7621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.9 (---) On Sat, Jan 22, 2011 at 11:16 PM, Bruno Haible wrote: > For (A), the list of options to be ignored during dependency extraction i= s the > following (cf. gnulib/build-aux/config.rpath): > =A0-rpath /some/path > =A0-Wl,-rpath -Wl,/some/path > =A0-Wl,-rpath,/some/path > =A0-lopt=3D-rpath -lopt=3D/some/path > =A0-Qoption ld -rpath -Qoption ld /some/path > =A0-R/some/path > =A0-R /some/path > =A0-blibpath:/some/path > =A0-Wl,-blibpath:/some/path > =A0+b /some/path > =A0-Wl,+b -Wl,/some/path Should there be an -Xlinker option in this list, too? -- Jack From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 21 05:32:29 2012 Received: (at control) by debbugs.gnu.org; 21 Nov 2012 10:32:29 +0000 Received: from localhost ([127.0.0.1]:58129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb7bY-0000ft-R2 for submit@debbugs.gnu.org; Wed, 21 Nov 2012 05:32:29 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:45197) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb7bW-0000fl-MT for control@debbugs.gnu.org; Wed, 21 Nov 2012 05:32:27 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so5828481lbk.3 for ; Wed, 21 Nov 2012 02:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; bh=rh0FhQaJhCav6vyymOw5HXuVJ/xzlW0dZElbOkxGJL8=; b=UPXCuglh/RRsAcZtZi0GUuv1WhtnGXc+Z34PmJIwyfydihv3pKinQQqlSBVGYTGHJH /aO6HGCpfIt8qNE8v61JdvDajyn/Q7SFOa7eIOboJ+W5uZE7b6C6WcP40Q3z7761nK/e jUGwLKH+7LB/hkMkXzSkutxIRE4QunY6GllX7tB7ySvOhxiIQCVSDaiyHJGOU+PdGqeg XDkgMjqnimMY4/SQBQkgyUV21E6ayoKxawSF26AVMtHRoXxQf385n9iA6O6M7Eie2MBt b9/gxGfJ2nql9K/pFNJZc/Rd/+61NgwtqBmuEU9XovLn8A7vpnNhTNnlDqq0bCDJcp+K kNDQ== Received: by 10.112.13.139 with SMTP id h11mr7246880lbc.99.1353493871597; Wed, 21 Nov 2012 02:31:11 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id z9sm29631lby.8.2012.11.21.02.31.09 (version=SSLv3 cipher=OTHER); Wed, 21 Nov 2012 02:31:10 -0800 (PST) Message-ID: <50ACAD6B.60204@gmail.com> Date: Wed, 21 Nov 2012 11:31:07 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: GNU bug tracker automated control server Subject: x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) severity 7621 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 13 07:13:12 2023 Received: (at 7621) by debbugs.gnu.org; 13 Feb 2023 12:13:12 +0000 Received: from localhost ([127.0.0.1]:47885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRXhn-0005SW-NV for submit@debbugs.gnu.org; Mon, 13 Feb 2023 07:13:12 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.220]:44943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRXhl-0005SL-C6 for 7621@debbugs.gnu.org; Mon, 13 Feb 2023 07:13:11 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1676290386; cv=none; d=strato.com; s=strato-dkim-0002; b=AOddIGRmDGakP9ghvi1JagK/j5bj2+XTzdUdOuHcdzXxa+rIsMcCqqZKBKLTB0S+YO xYl3Yx/VbvBX02z0IpGE7gVPsf2z2AC7Wm9J++9IzxQjWthGHZklXX3Mwb3Xqnqen4BU CbSZ376ai+GVv5fbZ48zXXSpirycegBr2DWgoQNq6fuNWD1kO1eNGs9MoLsV7UAtL38l bbuRSb3GCsGRPHeiBdpY4HxU4KEV7Kba9rQJWLrOgDeZMsRdluYtcGIaXx1g9tDnxXXr hGqfd4joVtzCPVCyenKNc4iWR0H/aP/6tUYCL4plgw+c0rjbYyywBfYCdm1uXEbUCrgg 8cDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1676290386; s=strato-dkim-0002; d=strato.com; h=Message-ID:Date:Subject:To:From:Cc:Date:From:Subject:Sender; bh=v6TypXsfc8b+m6VaUFdKby4DdvK+7WGqBZg5Fun5FTs=; b=GvelksDkYCI3VHz6URHfDra/Ii76AIy01WjltEpUybSOaBGKmUEbXPDB65KcDAzPs5 h+IDd6cStjfA3iFIQAd3M6zKjnkI+LN4Bhw4N647c86PNQcu5JbwucYfC1ptd+6Cn9hu gIUXRgt3+/0DyJIImuecGr+PAJrqi0Z3zUipvt8L8wHRa6USskmnvN5BQR1aswCmc+eL 3Q+LjKTEF/VuKor/FOxm8mloK3nIt7OZewahpppz+phApGCF//qvV17JgTp1izIqAuo+ A5N121C5C1qsLMXE2tyiS2CcNZSxCFf3y6aOLgYh72iqDfq1VWyl56PNXIv82gJ0T9mF CFPQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1676290386; s=strato-dkim-0002; d=clisp.org; h=Message-ID:Date:Subject:To:From:Cc:Date:From:Subject:Sender; bh=v6TypXsfc8b+m6VaUFdKby4DdvK+7WGqBZg5Fun5FTs=; b=tbdb+VyqE5Y7OhGJVQTNwAH9xKxu8tonVQf9xxfjAun3zLTHtyUFwvLuvovZNkh7IK 5v1tCF4J3MjHw+mEHiAhGVaE8VDgy7whrEXoIr9zoiISHJx4fn0/lO0kgFc3hGFYN0jp QiWg+S+UaqfeSwPTF84nrIUSVdiTr6+6W8cW7A5yt0jWM63KifOWIf9D9pr8I0HGiHt8 K6fsJdFNmyGWjYh5QzGYS9gUnN6sxX430jkLrfbRwm/s8Cn/12TZanKnipZcO/TvasDf XuZkh/ulT5nJggLqF2g+Gf0v1SWd3TFRnX7qr8w+d1sq3zam/5NJ/aVCxi2pPaO4H8BX IS9w== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPEj6cxcCeMDeYHxGbf4kcVajBlWQ==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.3.0 AUTH) with ESMTPSA id f83259z1DCD6aFz (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 13 Feb 2023 13:13:06 +0100 (CET) From: Bruno Haible To: 7621@debbugs.gnu.org Subject: Re: add a way to pass link dependencies Date: Mon, 13 Feb 2023 13:13:06 +0100 Message-ID: <3098037.NgBsaNRSFp@nimes> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 7621 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) To answer my own question: In 1) I wrote: > Typical values of LTLIBICONV are > > -liconv > -rpath /usr/local/lib -L/usr/local/lib -liconv > /usr/local/lib/libiconv.a > -rpath /usr/local/lib /usr/local/lib/libiconv.so > /usr/local/lib/libiconv.la But that is incorrect. /usr/local/lib/libiconv.a and /usr/local/lib/libiconv.la cannot be among the results, because the Gnulib 'havelib' macros would put "-L/usr/local/lib -liconv" into the LTLIBICONV variable instead. See lib-link.m4: LTLIB[]NAME="${LTLIB[]NAME}${LTLIB[]NAME:+ }-L$found_dir -l$name" So, the value of LTLIBICONV consists of libtool options *only*. No file names. I confirmed this, through some tests: When libiconv is installed with --disable-shared, then (regardless whether libiconv.la is deleted after installation): LTLIBICONV = -LPREFIX/lib -liconv LIBICONV = PREFIX/lib/libiconv.a Then I asked: > Now in which Automake provided variable could I stuff these linker options > or libtool options? The answer, as given by Ralf Wildenhues in https://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00146.html : "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." That is, we need to distinguish the case when libtool is used from the case where libtool is not used. * When libtool is used, we need to use $LTLIBICONV, not $LIBICONV. As documented in https://www.gnu.org/software/automake/manual/html_node/Libtool-Flags.html, these go into the library_LDFLAGS variable. In the libtool invocation, these *_LDFLAGS occur before the *.lo and *.la files, but this is not a problem since, as Ralf wrote, "libtool will reorder the command line so that `-l' flags appear after all encountered objects." * When libtool is not used, i.e. the target is library.a, we just ignore both $LIBICONV and $LTLIBICONV. The documentation is at https://www.gnu.org/software/automake/manual/html_node/A-Library.html. When linking a program that uses library.a, $LIBICONV or $LTLIBICONV will need to be used, depending on whether this linking happens without or with libtool. There is no need to unify these two cases (creating a .la library vs. creating a .a library). It's just two different cases, two different Automake rules.