Bug 290719

Summary:	valgrind-3.7.0 fails with automake-1.11.2 due to "pkglibdir" usage
Product:	[Developer tools] valgrind	Reporter:	blueness
Component:	general	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	normal	CC:	greg_g, rjwalsh, roamingangel, tom
Priority:	NOR
Version:	3.7.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	valgrind-3.7.0-automake-1.11.2.patch

Description blueness 2012-01-05 17:57:40 UTC

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

Comment 1 Tom Hughes 2012-01-05 18:06:07 UTC

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.

Comment 2 blueness 2012-01-05 18:17:47 UTC

(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.

Comment 3 Gregorio Guidi 2012-01-06 18:34:43 UTC

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

Comment 4 Robert Walsh 2012-02-13 03:37:32 UTC

Seeing this on MacOS X with MacPorts automake, too.

Comment 5 Tom Hughes 2012-02-21 15:41:59 UTC

I'm seeing it on F17 Alpha as well.

Comment 6 Tom Hughes 2012-02-21 15:58:37 UTC

I have committed your patch as r12396.