Version: 3.7.0 OS: Linux When doing an autoreconf on the build system, automake 1.11.2 fails to expand the main Makefile.am and coregrind/Makefile.am because of stricter rules on pkg dir variables. In particular, it fails on pkglib_DATA. Naively patching and changing pkglib to pkgdata (as required by the new automake) "works", but then this installs the .xml files and default.supp in /usr/share/valgrind rather than /usr/lib/valgrind. This breaks the valgrind binaries which expect to find those files in the old location. Two approaches here: either hack up the build system to reproduce the old behavior of installing int /usr/lib/valgrind, or retain the new location of /usr/share/valgrind for those files and hack up the rest of the code to look for the .xml and default.supp in the new location. The later is more in line with file system hierarchy standards. See https://bugs.gentoo.org/show_bug.cgi?id=397429 Reproducible: Always Steps to Reproduce: 1. Install automake 1.11.2 2. untar valgrind 3.7.0 and run autoreconf or any other autotool that invokes automake. Expected Results: It should finish auto configuring and produce the correct Makefile.in's
You shouldn't really be running autoreconf on a packaged version - that's something for the developers to run when preparing a release. On top of which, we normally use the autogen.sh script in the svn tree to update autoconf etc rather than running autoreconf.
(In reply to comment #1) > You shouldn't really be running autoreconf on a packaged version - that's > something for the developers to run when preparing a release. > > On top of which, we normally use the autogen.sh script in the svn tree to > update autoconf etc rather than running autoreconf. We add some patches which require it. We can deal with that at our end, but I think the valgrind team should know about this change in automake for future releases. It also brings up the issue of where data vs plugins should be installed. I'm not sure what the situation is with other distros, Gentoo may be unique in this situation since our users build directly "from source". But this may hit others that also have to hack the build system for their own reasons.
Created attachment 67519 [details] valgrind-3.7.0-automake-1.11.2.patch The attached patch is a quick way to implement solution 1: keep the files in the old location and prevent automake errors. HTH
Seeing this on MacOS X with MacPorts automake, too.
I'm seeing it on F17 Alpha as well.
I have committed your patch as r12396.