[Top][All Lists]

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

Re: Automake 1.16.1: problem with non-gnu make and gnulib

From: Thomas Martitz
Subject: Re: Automake 1.16.1: problem with non-gnu make and gnulib
Date: Wed, 28 Aug 2019 16:00:44 +0200

Am 25.08.19 um 00:03 schrieb Assaf Gordon:
Issue solved!

Thanks to Bruno Haible in

Quoting that message (and my reply):
On 2019-08-24 3:36 p.m., Bruno Haible wrote:
I think the problem is that 'bmake' does not consider the targets 'foo' and './foo' as being the same.

And indeed,

GNU hello and GNU datamash (which exhibit the problem)
have something like this in their

 hello_LDADD =  $(top_builddir)/lib/lib$(PACKAGE).a
 datamash_LDADD =  $(top_builddir)/lib/lib$(PACKAGE).a

While sed and coreutils (which don't have the problem) have:

  sed_sed_LDADD = sed/libver.a lib/libsed.a
  LDADD = src/libver.a lib/libcoreutils.a

So because of the "$(top_builddir)" the targets gets a "./"
prefix, and combined with that recent automake change,
they ended up being considered separated targets by "bmake".

So the immediate fix/work-around is to remove any path from
the libraries listed in xxx_LDADD in the projects themselves.

This change (regression?) seems to come from automake, perhaps
consider a bugfix for future versions.


I'm the author of that change. I'm sorry it causes problems for you. I agree it's a regression that should better be fixed.

I'm surprised it causes problems like this. The change causes only object files to be shorter, it shouldn't affect library targets. I'm also surprised that it affects the emission of a distdir-am rule or the the other changes in the generated you mention.

However, I'm not sure when I get time to look into it more deeply. I also don't have/use bmake.

Best regards

reply via email to

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