Summary: | dev-libs/g-wrap-1.9.9 fails to build (autotools issue) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Evil Compile Person <bugs> |
Component: | Eclasses | Assignee: | Scheme Project <scheme> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, chuck.wegrzyn, gentoo, jisakiel, mjinks, paul, roma1390, ryan, syscon780, tetromino |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.nongnu.org/g-wrap/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 226305 | ||
Attachments: |
patch for autotools.eclass
g-wrap ebuild |
Description
Evil Compile Person
2008-01-16 19:59:01 UTC
I get it to fail in aclocal. * Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/dev-libs/g-wrap-1.9.9/temp/aclocal-17781.out Here is aclocal-17781.out ideshow temp # more aclocal-17781.out ***** aclocal ***** ***** aclocal -I .. -I ../config -I /var/tmp/portage/dev-libs/g-wrap-1.9.9/work/ g-wrap-1.9.9/m4 aclocal-1.10: couldn't open directory `../config': No such file or directory sideshow temp # vapier: this bug is due your change to eaclocal in autotools.eclass, CVS commit 1.74 (and due to the fact that g-wrap makefiles are a mess). As a result, *all* versions of g-wrap in the tree currently fail to compile. You might want to look out whether other packages in portage are similarly affected. ***Devs: please change the bug component to "Eclasses and Profiles"! The -I ../config error is trivial to fix. The hard problem is that g-wrap uses the following construct in its Makefile.am: ACLOCAL_AMFLAGS = -I m4 @ACLOCAL_FLAGS@ where ACLOCAL_FLAGS is set by configure. The new behaviour for eaclocal is to automatically scan for ACLOCAL_AMFLAGS in Makefile.am and Makefile.in, so this is a major problem; the obvious workarounds are either ugly (shuffling Makefile.am's and Makefile.in's in and out of backup directories) or far too much work (rewriting the g-wrap build system). IMHO, the solution is to patch autotools.eclass so that the list of files that eaclocal scans for ACLOCAL_AMFLAGS would be a variable. So the ebuild could call something like AT_AMFLAGS_FILES="" AT_M4DIR="${S}/m4" eautoreconf Created attachment 152399 [details, diff]
patch for autotools.eclass
Patch to make the list of files that eaclocal scans for ACLOCAL_AMFLAGS be editable via the AT_AMFLAGS_FILES variable (i.e. setting AT_AMFLAGS_FILES="" would make eaclocal behave like it did before April 22 2008)
i cant see how it works properly regardless of autotools.eclass ... in fact, a quick test over here shows that it indeed doesnt work at all: $ autoreconf aclocal-1.10: unrecognized option `@ACLOCAL_FLAGS@' aclocal-1.10: Try `/usr/bin/aclocal-1.10 --help' for more information. autoreconf-2.61: aclocal failed with exit status: 1 fix the makefiles in question Still doesn't build for me. (this means I can reproduce it too) cd ${S} ln -s m4 config find . -name Makefile.in -o -name Makefile.am -exec sed -i s/@ACLOCAL_FLAGS@//g {} \; "works for me" (TM) The above patch didn't work for me either. Can someone please provide a fixed ebuild that will actually emerge successfully? Or even better provide a folder ready to put in an overlay? Christian Schmidt's patch worked OK for me, but it would be cool if someone could fix the ebuild in portage. Created attachment 159720 [details]
g-wrap ebuild
(In reply to comment #10) > Created an attachment (id=159720) [edit] > g-wrap ebuild > Thankyou Worked for me. I used the script to build g-wrap-1.9.6-r3 without error messages. I changed only the KEYWORDS to match version 1.9.6-r3. (In reply to comment #10) > Created an attachment (id=159720) [edit] > g-wrap ebuild > v1.9.9 ebuild worked for me. Thank you! does this problem occur for 1.9.11? (In reply to comment #12) > (In reply to comment #10) > > Created an attachment (id=159720) [edit] > > g-wrap ebuild > v1.9.9 ebuild worked for me. > Thank you! And for me. Thanks a lot! I can also report success using the ebuild with g-wrap-1.9.6-r3, having changed the KEYWORDS line. Thanks very much! What KEYWORDS are you folks referring to? the version: g-wrap-1.9.6-r3.ebuild has: KEYWORDS="alpha amd64 ppc sparc x86" version: g-wrap-1.9.9.ebuild (posted here has:) KEYWORDS="~alpha ~amd64 ~hppa ~ppc ~ppc64 ~sparc ~x86" I'm having problem as well after upgrading to gcc-4.3.2-r3 * Running eautoreconf in '/var/tmp/portage/dev-libs/g-wrap-1.9.6-r3/work/g-wrap-1.9.6/libffi' ... * Running aclocal -I .. -I ../config -I /var/tmp/portage/dev-libs/g-wrap-1.9.6-r3/work/g-wrap-1.9.6/m4 ... [ !! ] * Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/dev-libs/g-wrap-1.9.6-r3/temp/aclocal-18741.out * * ERROR: dev-libs/g-wrap-1.9.6-r3 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2667: Called eautoreconf * environment, line 867: Called eautoreconf * environment, line 875: Called eaclocal * environment, line 814: Called autotools_run_tool 'aclocal' '-I' '..' '-I' '../config' '-I' '/var/tmp/portage/dev-libs/g-wrap-1.9.6-r3/work/g-wrap-1.9.6/m4' * environment, line 365: Called die * The specific snippet of code: * die "Failed Running $1 !"; * The die message: * Failed Running aclocal ! I've tried g-wrap 1.9.9 from portage, the same problem This version removed. |