Am 25.08.19 um 00:03 schrieb Assaf Gordon:
Issue solved!
Thanks to Bruno Haible in
https://lists.gnu.org/r/bug-gnulib/2019-08/msg00064.html
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 Makefile.am:
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.
However,
This change (regression?) seems to come from automake, perhaps
consider a bugfix for future versions.
Hello,
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 Makefile.in 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
