[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pointless automake error about libtool libraries

From: Ralf Wildenhues
Subject: Re: pointless automake error about libtool libraries
Date: Mon, 21 Aug 2006 13:57:47 +0200
User-agent: Mutt/1.5.12 (2006-08-10)

Hello Bruno,

* Bruno Haible wrote on Mon, Aug 21, 2006 at 01:34:04PM CEST:
> I have a Makefile.am containing
> line 15:   noinst_LTLIBRARIES = libgettextlib.la
> line 268:  lib_LTLIBRARIES = libgettextlib.la

So which should automake use?

> automake-1.9.6 gives an error on it:

And rightly so.

> gnulib-lib/Makefile.am:15: libgettextlib.la multiply defined in condition TRUE
> gnulib-lib/Makefile.am:15: `libgettextlib.la' should be built for `noinst' ...

> This error is unjustified: it could simply ignore the noinst_LTLIBRARIES
> line. The comment in automake's source says
>       # We reject libraries which are installed in several places
>       # in the same condition, because we can only specify one
>       # `-rpath' option.
> and indeed for linking to not-installed libraries no -rpath option is needed.

But I don't see a good reason why automake should prefer one definition
over the other.  Had the user specified them both inadvertently, it
would have helped him to find this bug.

> You could say: remove the noinst_LTLIBRARIES line yourself! Well, this
> situation occurs with gnulib-tool, which generates the noinst_LTLIBRARIES.
> I would need to add an extra option to gnulib-tool, to have it omit the
> noinst_LTLIBRARIES line, just to overcome this pointless automake error.

I don't see where this choice is "obvious".  IOW, we would need a
generalizable definition of what to do with a library connected with
multiple (non-)installations, in the light that Libtool itself only (and
rightly!) allows at most one installation directory.

This is connected with tests/libtool8.test and PR automake/285.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]