GNU logs - #7621, boring messages

Message sent to owner <at> debbugs.gnu.org, bug-automake@HIDDEN:

Subject: bug#7621: add a way to pass link dependencies
Resent-From: Bruno Haible <bruno@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sun, 12 Dec 2010 14:38:01 +0000
Resent-Message-ID: <handler.7621.B.12921646275614 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 7621 <at> debbugs.gnu.org
From: Bruno Haible <bruno@HIDDEN>
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@HIDDEN>
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Bruno Haible <bruno@HIDDEN>
Subject: bug#7621: Acknowledgement (add a way to pass link dependencies)
Message-ID: <handler.7621.B.12921646275614.ack <at> debbugs.gnu.org>
References: <201012121543.01508.bruno@HIDDEN>
X-Gnu-PR-Message: ack 7621
X-Gnu-PR-Package: automake
Reply-To: 7621 <at> debbugs.gnu.org
Date: Sun, 12 Dec 2010 14:38:01 +0000

Thank you for filing a new bug report with GNU.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-automake@HIDDEN

If you wish to submit further information on this problem, please
send it to 7621 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
7621: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D7621
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to owner <at> debbugs.gnu.org, bug-automake@HIDDEN:

Subject: bug#7621: add a way to pass link dependencies
Resent-From: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 22 Jan 2011 09:20:02 +0000
Resent-Message-ID: <handler.7621.B7621.12956879777493 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Bruno Haible <bruno@HIDDEN>
Cc: 7621 <at> debbugs.gnu.org
Date: Sat, 22 Jan 2011 10:27:27 +0100
From: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>
Message-ID: <20110122092727.GE31878@HIDDEN>
References: <201012121543.01508.bruno@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201012121543.01508.bruno@HIDDEN>
Organization: Institute for Numerical Simulation, University of Bonn
User-Agent: Mutt/1.5.20 (2010-08-04)
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

[ 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

Message sent to owner <at> debbugs.gnu.org, bug-automake@HIDDEN:

Subject: bug#7621: add a way to pass link dependencies
Resent-From: Bruno Haible <bruno@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 22 Jan 2011 12:09:02 +0000
Resent-Message-ID: <handler.7621.B7621.129569810421568 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>
Cc: 7621 <at> debbugs.gnu.org
From: Bruno Haible <bruno@HIDDEN>
Date: Sat, 22 Jan 2011 13:16:14 +0100
User-Agent: KMail/1.9.9
References: <201012121543.01508.bruno@HIDDEN>
	<20110122092727.GE31878@HIDDEN>
In-Reply-To: <20110122092727.GE31878@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201101221316.14882.bruno@HIDDEN>
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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

Message sent to owner <at> debbugs.gnu.org, bug-automake@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#7621: add a way to pass link dependencies
Resent-From: Jack Kelly <jack@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 22 Jan 2011 20:45:02 +0000
Resent-Message-ID: <handler.7621.B7621.129572905517521 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 7621
X-GNU-PR-Package: automake
X-GNU-PR-Keywords: 
To: Bruno Haible <bruno@HIDDEN>
Cc: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>, 7621 <at> debbugs.gnu.org
Received: via spool by 7621-submit <at> debbugs.gnu.org id=B7621.129572905517521
          (code B ref 7621); Sat, 22 Jan 2011 20:45:02 +0000
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 <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1PgkJj-0004YY-5A
	for submit <at> 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 <endgame.dos@HIDDEN>) id 1PgkJh-0004YN-Ps
	for 7621 <at> debbugs.gnu.org; Sat, 22 Jan 2011 15:44:14 -0500
Received: by qyk34 with SMTP id 34so1637065qyk.3
	for <7621 <at> 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@HIDDEN>
References: <201012121543.01508.bruno@HIDDEN>
	<20110122092727.GE31878@HIDDEN>
	<201101221316.14882.bruno@HIDDEN>
Date: Sun, 23 Jan 2011 07:52:10 +1100
X-Google-Sender-Auth: R79JSrINPrgJDaixvncJHIdz0e4
Message-ID: <AANLkTineX18xELRbxkdbJq0o8o9pym-0XzyR715gdZAk@HIDDEN>
From: Jack Kelly <jack@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -3.9 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -3.9 (---)

On Sat, Jan 22, 2011 at 11:16 PM, Bruno Haible <bruno@HIDDEN> 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

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 21 Nov 2012 10:32:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 21 05:32:29 2012
Received: from localhost ([127.0.0.1]:58129 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Tb7bY-0000ft-R2
	for submit <at> 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 <stefano.lattarini@HIDDEN>) id 1Tb7bW-0000fl-MT
	for control <at> debbugs.gnu.org; Wed, 21 Nov 2012 05:32:27 -0500
Received: by mail-lb0-f172.google.com with SMTP id y2so5828481lbk.3
	for <control <at> debbugs.gnu.org>; 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@HIDDEN>
Date: Wed, 21 Nov 2012 11:31:07 +0100
From: Stefano Lattarini <stefano.lattarini@HIDDEN>
MIME-Version: 1.0
To: GNU bug tracker automated control server <control <at> debbugs.gnu.org>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: 0.1 (/)

severity 7621 wishlist
thanks

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.