Re: Automake 1.16.1: problem with non-gnu make and gnulib
Hello Bob, On 2019-08-24 5:26 p.m., Bob Friesenhahn wrote: On Sat, 24 Aug 2019, Assaf Gordon wrote: hello_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a datamash_LDADD = $(top_builddir)/lib/lib$(PACKAGE).a This seems like a bug in those two packages. It should never be desirable to refer to the build directory other than by using the knowledge that the build is done using the current directory. Why do you say so? Is there a reference to somewhere authoritative with such recommendation? "top_builddir" is supposed to point to the build directory, and similarly there's "abs_top_builddir", as well as some others: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Preset-Output-Variables.html Why shouldn't they be used? However, This change (regression?) seems to come from automake, perhaps consider a bugfix for future versions. Unfortunately, the 'hello' program is supposed to be a reference example of the right things to do. That, and the fact it it was working fine for many years and automake versions is the reason I ask why do you think it should not be used. Thanks, - assaf
Re: Automake 1.16.1: problem with non-gnu make and gnulib
On Sat, 24 Aug 2019, Assaf Gordon wrote: 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". This seems like a bug in those two packages. It should never be desirable to refer to the build directory other than by using the knowledge that the build is done using the current directory. 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. It would be good if Automake can warn about unnecessary use of $(top_builddir) and make any necessary corrections. Unfortunately, the 'hello' program is supposed to be a reference example of the right things to do. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Automake 1.16.1: problem with non-gnu make and gnulib
Assaf Gordon 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
Re: Automake 1.16.1: problem with non-gnu make and gnulib
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. regards, - assaf
Re: Automake 1.16.1: problem with non-gnu make and gnulib
Hello Mathieu, Karl,
On 2019-08-24 11:43 a.m., Mathieu Lirzin wrote:
On Sat, 24 Aug 2019, Assaf Gordon wrote:
I've encountered a problem where a released tarball (of 'make dist')
generated by Automake-1.16.1 fails to build with non-gnu make (e.g.
"bmake" on BSDs).
The exact same project and 'make dist' with automake-1.15 builds fine.
One convenient way to detect what caused this problem would be to do a
‘git bisect’ session on Automake VCS repository and analyse the diff of
the commit introducing the failure.
The offending commit is:
---
https://git.sv.gnu.org/cgit/automake.git/commit/?id=f4e91bfc
commit f4e91bfc490da63209aad19636568da3b955dcd4
Date: Mon Mar 13 12:41:59 2017 +0100
automake: Shorter object file names under subdir-objects
Combining the 'subdir-objects' option with target-specific flags had
the consequence of producing long object file names. This was done to
preventively ensure the uniqueness of object file names. We are now
using shorter names by default, and handle long names when an actual
conflict is detected. This will hopefully reduce the necessity of
using the 'prog_SHORTNAME' facility.
Example:
previously:
AUTOMAKE_OPTIONS = subdir-objects
bin_PROGRAMS += path/to/foo
path_to_foo_CFLAGS = $(AM_CFLAGS) -g
resulted in objects:
sub/path_to_foo-foo.o
now object file name is:
sub/foo-foo.o
---
On 2019-08-24 3:14 p.m., Karl Berry wrote:> Low-tech idea similar to git
bisect: do the 1.15 build and 1.16
build in separate dirs, diff -r the Makefile.am's.
Good idea.
I'm attaching the diff of the Makefile.in (which is the file generated
by automake) when building "gnu hello".
Some targets changed location in the file, but I don't think that matters.
The one thing the pops up is that in the "good" version,
there are "distdir distdir-am dist dist-all" targets,
while in the "bad" version there is no "distdir-am" target.
Later on there's this:
-distdir: $(DISTFILES)
+distdir: $(BUILT_SOURCES)
+ $(MAKE) $(AM_MAKEFLAGS) distdir-am
+
+distdir-am: $(DISTFILES)
I tested by simply doing:
git clone git://git.sv.gnu.org/hello.git
cd hello
./bootstrap
./configure
bmake
Once with automake commit f4e91bfc (bad one),
and once with the preceeding commit c946ae (good one).
-
investigation continues...
thanks,
- assaf
--- hello-AM-GOOD/Makefile.in 2019-08-24 14:58:59.0 -0600
+++ hello-AM-BAD/Makefile.in 2019-08-24 14:51:22.0 -0600
@@ -1,7 +1,7 @@
-# Makefile.in generated by automake 1.15a from Makefile.am.
+# Makefile.in generated by automake 1.16.1 from Makefile.am.
# @configure_input@
-# Copyright (C) 1994-2017 Free Software Foundation, Inc.
+# Copyright (C) 1994-2018 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
@@ -249,6 +249,9 @@
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
+am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(infodir)" \
+ "$(DESTDIR)$(man1dir)"
+PROGRAMS = $(bin_PROGRAMS)
LIBRARIES = $(noinst_LIBRARIES)
AM_V_AR = $(am__v_AR_@AM_V@)
am__v_AR_ = $(am__v_AR_@AM_DEFAULT_V@)
@@ -296,9 +299,6 @@
lib/xalloc-die.$(OBJEXT) lib/xstriconv.$(OBJEXT) \
lib/xstrndup.$(OBJEXT)
lib_libhello_a_OBJECTS = $(am_lib_libhello_a_OBJECTS)
-am__installdirs = "$(DESTDIR)$(bindir)" "$(DESTDIR)$(infodir)" \
- "$(DESTDIR)$(man1dir)"
-PROGRAMS = $(bin_PROGRAMS)
am_hello_OBJECTS = src/hello.$(OBJEXT)
hello_OBJECTS = $(am_hello_OBJECTS)
hello_DEPENDENCIES = $(am__DEPENDENCIES_1) \
@@ -458,7 +458,8 @@
$(RECURSIVE_CLEAN_TARGETS) \
$(am__extra_recursive_targets)
AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \
- cscope check recheck distdir dist dist-all distcheck
+ cscope check recheck distdir distdir-am dist dist-all \
+ distcheck
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) \
$(LISP)config.in
# Read a list of newline-separated strings from the standard input,
@@ -1677,6 +1678,48 @@
distclean-hdr:
-rm -f config.h stamp-h1
+install-binPROGRAMS: $(bin_PROGRAMS)
+ @$(NORMAL_INSTALL)
+ @list='$(bin_PROGRAMS)'; test -n "$(bindir)" || list=; \
+ if test -n "$$list"; then \
+ echo " $(MKDIR_P) '$(DESTDIR)$(bindir)'"; \
+ $(MKDIR_P) "$(DESTDIR)$(bindir)" || exit 1; \
+ fi; \
+ for p in $$list; do echo "$$p $$p"; done | \
+ sed 's/$(EXEEXT)$$//' | \
+ while read p p1; do if test -f $$p \
+ ; then echo "$$p"; echo "$$p"; else :; fi; \
+ done | \
+ sed -e 'p;s,.*/,,;n;h' \
+ -e 's|.*|.|' \
+ -e 'p;x;s,.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/' | \
+ sed 'N;N;N;s,\n, ,g' | \
+ $(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1 } \
+ { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
+ if ($$2 == $$4) files[d] = files[d] " " $$1; \
+ else { print "f", $$3 "/" $$4, $$1; } } \
+ END { for (d in files) print "f", d, files[d] }' | \
+ while read type dir fil
Re: Automake 1.16.1: problem with non-gnu make and gnulib
Hello Assaf, Assaf Gordon writes: > On 2019-08-24 7:34 a.m., Bob Friesenhahn wrote: >> On Sat, 24 Aug 2019, Assaf Gordon wrote: > >>> >>> I've encountered a problem where a released tarball (of 'make dist') >>> generated by Automake-1.16.1 fails to build with non-gnu make (e.g. >>> "bmake" on BSDs). >>> The exact same project and 'make dist' with automake-1.15 builds fine. >> >> The problem may very well have to do with parts obtained from gnulib >> or an implementation artifact from the template Makefiles. > > I certainly agree - but it seems like a regression in Automake where > a structure that worked for several years (and several automake > versions) now stopped working. > > I'm looking for any hints or ideas as to what changed or what is causing > the failure... One convenient way to detect what caused this problem would be to do a ‘git bisect’ session on Automake VCS repository and analyse the diff of the commit introducing the failure. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Automake 1.16.1: problem with non-gnu make and gnulib
On 2019-08-24 7:34 a.m., Bob Friesenhahn wrote: On Sat, 24 Aug 2019, Assaf Gordon wrote: I've encountered a problem where a released tarball (of 'make dist') generated by Automake-1.16.1 fails to build with non-gnu make (e.g. "bmake" on BSDs). The exact same project and 'make dist' with automake-1.15 builds fine. The problem may very well have to do with parts obtained from gnulib or an implementation artifact from the template Makefiles. I certainly agree - but it seems like a regression in Automake where a structure that worked for several years (and several automake versions) now stopped working. I'm looking for any hints or ideas as to what changed or what is causing the failure... I did a test build of GraphicsMagick using Illumos '/usr/bin/make' under OmniOSce and under Ubuntu 18.04 LTS using 'bmake'. The test builds succeeded (even parallel builds), including the test suite. GraphicsMagick uses a non-recursive build, but does not depend on gnulib or 'po' files. Thanks for testing!
Re: Automake 1.16.1: problem with non-gnu make and gnulib
On Sat, 24 Aug 2019, Assaf Gordon wrote: Hello, I've encountered a problem where a released tarball (of 'make dist') generated by Automake-1.16.1 fails to build with non-gnu make (e.g. "bmake" on BSDs). The exact same project and 'make dist' with automake-1.15 builds fine. It has something to do with non-recursive makefile structure common to some gnu projects. The problem may very well have to do with parts obtained from gnulib or an implementation artifact from the template Makefiles. I did a test build of GraphicsMagick using Illumos '/usr/bin/make' under OmniOSce and under Ubuntu 18.04 LTS using 'bmake'. The test builds succeeded (even parallel builds), including the test suite. GraphicsMagick uses a non-recursive build, but does not depend on gnulib or 'po' files. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Automake 1.16.1: problem with non-gnu make and gnulib
Hello, I've encountered a problem where a released tarball (of 'make dist') generated by Automake-1.16.1 fails to build with non-gnu make (e.g. "bmake" on BSDs). The exact same project and 'make dist' with automake-1.15 builds fine. It has something to do with non-recursive makefile structure common to some gnu projects. I haven't been able to pin-point the issue, so if anyone has some ideas or suggestions they are very welcomed. One way to reproduce (with GNU hello): 1. with "automake-1.15": $ automake --version | head -1 automake (GNU automake) 1.15 $ git clone git://git.sv.gnu.org/hello.git $ cd hello # Build, then clean - emulating a 'make dist' situation $ ./bootstrap && ./configure && make [... all ok ...] $ make clean # Now build with BSD Make $ bmake [ .. builds ok ... ] 2. Repeat the exact same steps with automake-1.16.1, and "bmake" will fail with: $ bmake [...] Making all in po depbase=`echo src/hello.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -Ilib -I./lib -Isrc -I./src-g -O2 -MT src/hello.o -MD -MP -MF $depbase.Tpo -c -o src/hello.o src/hello.c && mv -f $depbase.Tpo $depbase.Po bmake[2]: don't know how to make ./lib/libhello.a. Stop bmake[2]: stopped in /tmp/hello-test/hello *** Error code 1 The 'bmake' here is BSD-make from the stock Debian 'bmake' package, but the same happens on FreeBSD. The same happens in my package (GNU datamash). It doesn't happen in GNU sed or GNU coreutils - I'm still trying to find out what are the differences between the packages that do fail and don't fail... If this rings any bells, please let me know. Thanks, - assaf
