SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Current tip of valgrind git branch 'master' fails to build because "No rule to make target 'filter_sized_delete', needed by 'all-am'." STEPS TO REPRODUCE 1. commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master, origin/master, origin/HEAD) Date: Mon May 22 19:49:08 2023 +0200 2. ./configure 3. make -j4 OBSERVED RESULT make[3]: Entering directory '/bigdata/valgrind/memcheck/tests' Making all in . make[4]: Entering directory '/bigdata/valgrind/memcheck/tests' make[4]: *** No rule to make target 'filter_sized_delete', needed by 'all-am'. make[4]: Target 'all-am' not remade because of errors. make[4]: Leaving directory '/bigdata/valgrind/memcheck/tests' EXPECTED RESULT Successful build SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: $ uname -a 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 $ gcc --version gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4) (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
(In reply to John Reiser from comment #0) > STEPS TO REPRODUCE > 1. commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master, > origin/master, origin/HEAD) > Date: Mon May 22 19:49:08 2023 +0200 > 2. ./configure > 3. make -j4 Did you ./autogen.sh before ./configure ?
Yes, this is part of a persistent local git clone, and I did run "./autogen.sh" when I did the original clone. I have run several successful "git pull; make -j4" since then, over a span of several months.
The problem no longer appears in: commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master, origin/master, origin/HEAD) Date: Mon May 22 19:49:08 2023 +0200 after explicit "./autogen.sh" before "make -j4". I did not expect that running autogen.sh would be required after "git pull". This seems peculiar.
(In reply to John Reiser from comment #3) > The problem no longer appears in: > commit cb684b50e7d4d845b56abea72fd9b9925fed644e (HEAD -> master, > origin/master, origin/HEAD) > Date: Mon May 22 19:49:08 2023 +0200 > after explicit "./autogen.sh" before "make -j4". > > I did not expect that running autogen.sh would be required after "git pull". > This seems peculiar. The full sequence of the "fix" was: "git pull; ./autogen.sh; ./configure; make -j4".
For 9fb974c359e127caa930fc2ccf49218778e7c584 I noticed that filter_sized_delete was reduntant so removed it. That means memcheck/tests/Makefile needs to be regenerated. I always run autogen.sh whenever a Makefile.am changes
(In reply to Paul Floyd from comment #5) > I always run autogen.sh whenever a Makefile.am changes So the Makefile has two missing dependencies: all: Makefile Makefile: Makefile.am ./autogen.sh and then the documentation for "$ info make", section 3.5 "How Makefiles Are Remade", says that the Makefile will be automatically re-read so that the invoking "make" will use the new Makefile.
Here is what GCC's Makefile contains # -------------------------------- # Regenerating top level configury # -------------------------------- # Rebuilding Makefile.in, using autogen. AUTOGEN = autogen $(srcdir)/Makefile.in: # $(srcdir)/Makefile.tpl $(srcdir)/Makefile.def cd $(srcdir) && $(AUTOGEN) Makefile.def # Rebuilding Makefile. Makefile: $(srcdir)/Makefile.in config.status CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status config.status: configure CONFIG_SHELL="$(SHELL)" $(SHELL) ./config.status --recheck # Rebuilding configure. AUTOCONF = autoconf $(srcdir)/configure: # $(srcdir)/configure.ac $(srcdir)/config/acx.m4 \ $(srcdir)/config/override.m4 $(srcdir)/config/proginstall.m4 \ $(srcdir)/config/elf.m4 $(srcdir)/config/isl.m4 \ $(srcdir)/libtool.m4 $(srcdir)/ltoptions.m4 $(srcdir)/ltsugar.m4 \ $(srcdir)/ltversion.m4 $(srcdir)/lt~obsolete.m4 cd $(srcdir) && $(AUTOCONF)
(In reply to Paul Floyd from comment #7) > Here is what GCC's Makefile contains Yes, valgrind should use essentially the same setup. In ancient times (pre-git) there was a conceptual barrier that Makefile.am and files that depend on it directly, would be changed only by Team members making a new release; and the consumers of the release would perform the "autogen; configure". Now "git pull" removes that barrier, so ALL dependencies must be recorded explicitly. > Makefile: $(srcdir)/Makefile.in config.status > CONFIG_FILES=$@ CONFIG_HEADERS= $(SHELL) ./config.status Yes, I had figured out yesterday that Makefile would need to be re-generated by running config.status. > config.status: configure > CONFIG_SHELL="$(SHELL)" $(SHELL) ./config.status --recheck This is a cicularity that logically might require two passes to stabilize: running ./configure changes ./config.status, and running ./config.status changes ./configure. Perhaps the --recheck does that?