Assaf Gordon <assafgor...@gmail.com> writes: > 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.
Excellent! :-) > 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. Unfortunately I currently don't have much time for Automake. If somebody is willing to do the investigation job and fix the code, I am willing to apply the patch. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
