Building app-text/recode-3.6_p17-r2 the autoconfigure scripts don't work properly. I get a message "--print-ac-dir invalid option". I'm building on a remote boot system mounted over NFS. I got a hint from bug 238710, which gave me the idea to temporary mount an EXT3 filesystem in /var/tmp/portage after which it worked. I guess whatever was fixed back then, is broken again now.
This could probably be fixed simply by removing aclocal.sh from toplevel Makefile.am - whatever was wrong with plain aclocal at the time that script was written seems to have long been fixed. After all, it's ben over a decade since recode 3.6 release. There's i.e. an interesting bug, if you were to try to regenerate one of recode source files from its flex sources, probably ever since flex gained option of reusing scanners (back in version 2.5.33 (2006-02-20)). I think I found a proper fix for that, but I know almost nothing about flex, so I can't be sure.
I have the same problem. Building on local system. Using XFS file system. * Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/app-text/recode-3.6_p17-r2/temp/aclocal.out * ERROR: app-text/recode-3.6_p17-r2 failed (prepare phase): * Failed Running aclocal ! * * Call stack: * ebuild.sh, line 85: Called src_prepare * environment, line 3066: Called eautoreconf * environment, line 900: Called eaclocal * environment, line 807: Called autotools_run_tool '--at-m4flags' 'aclocal' '-I' 'm4' * environment, line 677: Called die * The specific snippet of code: * die "Failed Running $1 !"; * If you need support, post the output of `emerge --info '=app-text/recode-3.6_p17-r2'`, * the complete build log and the output of `emerge -pqv '=app-text/recode-3.6_p17-r2'`. /usr/lib64/portage/bin/isolated-functions.sh: line 214: wait: `Failed Running aclocal !': not a pid or valid job spec * The complete build log is located at '/var/tmp/portage/app-text/recode-3.6_p17-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-text/recode-3.6_p17-r2/temp/environment'. * Working directory: '/var/tmp/portage/app-text/recode-3.6_p17-r2/work/recode-3.6' * S: '/var/tmp/portage/app-text/recode-3.6_p17-r2/work/recode-3.6' My environment is attached.
Created attachment 314869 [details] emerge info
@coment 2: there was no need for a "me too" and the fix is already described.
autom4te-2.69 error automatic de-ANSI-fication support has bin removed same error when compile lame-3.99.5 make.conf -march=corei7 gcc 4.6.3
sys-devel/automake downgrade from 1.12.1 to 1.11.5 resolve this problem in file /etc/portage.mask add string =sys-devel/automake-1.12.1
sorry, in file /etc/portage/portage.mask add string
So, 'WANT_AUTOMAKE="1.11"' in the ebuild would be the preferred workaround.
Created attachment 315017 [details, diff] my workaround Bah, WANT_AUTOMAKE is only a 'proper' solution if you don't know what the problem is and you do. Removing ACLOCAL = ./aclocal.sh @ACLOCAL@ from toplevel Makefile.am AM_C_PROTOTYPES from configure.in and 'ansi2knr' from AUTOMAKE_OPTIONS in src/Makefile.am should suffice (all the use of PROTOTYPES is or-ed with __STDC__, so there should be no need for append_cppflags). Also, just so my kludge doesn't get lost, attaching the change that fixes testsuite, in case parser gets regenerated with recent flex.
(In reply to comment #6) > sys-devel/automake downgrade from 1.12.1 to 1.11.5 resolve this problem > > in file /etc/portage.mask add string > =sys-devel/automake-1.12.1 I have seen this quite sometime. Rechecking confirmed that downgrading fixes many issues I have. Probably automake-1.12.1 has a problem in general.
@comment 10: what problem exactly ? In NEWS: - The '--acdir' option of aclocal is deprecated, and will probably be removed in the next major Automake release (1.13). You should use the options '--automake-acdir' and '--system-acdir' instead (which have been introduced in Automake 1.11.2). - Support for automatic de-ANSI-fication has been removed.
(In reply to comment #11) > @comment 10: what problem exactly ? * Running aclocal -I . ... [ ok ] * Running autoconf -I . ... [ ok ] * Running automake --add-missing --copy ... [ !! ] * Failed Running automake ! * * Include in your bugreport the contents of: * * /var/tmp/portage/app-admin/eselect-1.3.1-r1/temp/automake.out automake.out: configure.ac:5: version mismatch. This is Automake 1.11.5, configure.ac:5: but the definition used by this AM_INIT_AUTOMAKE configure.ac:5: comes from Automake 1.11.2. You should recreate configure.ac:5: aclocal.m4 with aclocal and run automake again. bin/Makefile.am:10: `%'-style pattern rules are a GNU make extension bin/Makefile.am:19: foreach f, $(symlinks: non-POSIX variable name bin/Makefile.am:19: (probably a GNU make extension) bin/Makefile.am:21: `%'-style pattern rules are a GNU make extension doc/Makefile.am:3: foreach f, $(doc_files: non-POSIX variable name doc/Makefile.am:3: (probably a GNU make extension) doc/Makefile.am:5: foreach f, $(doc_files: non-POSIX variable name doc/Makefile.am:5: (probably a GNU make extension) doc/Makefile.am:7: `%'-style pattern rules are a GNU make extension doc/Makefile.am:10: foreach f, $(doc_files: non-POSIX variable name doc/Makefile.am:10: (probably a GNU make extension) libs/Makefile.am:38: `%'-style pattern rules are a GNU make extension libs/Makefile.am:41: `%'-style pattern rules are a GNU make extension man/Makefile.am:20: foreach f, $(symlinks: non-POSIX variable name man/Makefile.am:20: (probably a GNU make extension) man/Makefile.am:22: `%'-style pattern rules are a GNU make extension Makefile.am:18: foreach f, $(doc_files: non-POSIX variable name Makefile.am:18: (probably a GNU make extension) Makefile.am:21: `%'-style pattern rules are a GNU make extension So eaclocal got run but somehow the buildsystem things different.
Created attachment 315069 [details, diff] recode-3.6.patch (In reply to comment #9) > Removing > ACLOCAL = ./aclocal.sh @ACLOCAL@ > from toplevel Makefile.am > AM_C_PROTOTYPES > from configure.in and 'ansi2knr' from AUTOMAKE_OPTIONS in src/Makefile.am
*** Bug 420779 has been marked as a duplicate of this bug. ***
configure.ac:5: version mismatch. This is Automake 1.11.5, configure.ac:5: but the definition used by this AM_INIT_AUTOMAKE configure.ac:5: comes from Automake 1.11.2. You should recreate configure.ac:5: aclocal.m4 with aclocal and run automake again. What does above have to do with automake 1.12 ? But indeed something *is* broken about automake 1.12, namely it's ebuild. It doesn't regenerate info pages correctly - I'll file about it shortly.
+ 13 Jun 2012; Jeremy Olexa <darkside@gentoo.org> recode-3.6_p17-r2.ebuild: + Set WANT_AUTOMAKE=1.11 to workaround bug 419455
(In reply to comment #16) > + 13 Jun 2012; Jeremy Olexa <darkside@gentoo.org> recode-3.6_p17-r2.ebuild: > + Set WANT_AUTOMAKE=1.11 to workaround bug 419455 Why such a workaround is considered FIXED ? Do you expect new recode release ?
(In reply to comment #16) > + 13 Jun 2012; Jeremy Olexa <darkside@gentoo.org> recode-3.6_p17-r2.ebuild: > + Set WANT_AUTOMAKE=1.11 to workaround bug 419455 if we oblige to use automake-1.12, then delete AM_C_PROTOTYPES and asi2knr should work we can put following into src_prepare sed -i -e '/^AM_C_PROTOTYPES/d' configure.in || die sed -i -e 's/ansi2knr//' src/Makefile.am || die
(In reply to Yixun Lan from comment #18) > (In reply to comment #16) > > + 13 Jun 2012; Jeremy Olexa <darkside@gentoo.org> recode-3.6_p17-r2.ebuild: > > + Set WANT_AUTOMAKE=1.11 to workaround bug 419455 > > if we oblige to use automake-1.12, then delete AM_C_PROTOTYPES and asi2knr > should work > > we can put following into src_prepare > sed -i -e '/^AM_C_PROTOTYPES/d' configure.in || die > sed -i -e 's/ansi2knr//' src/Makefile.am || die Could you reopen it? After this change, it work well even with 1.14. Thank you
And also actual maintainer did similiar thing - https://github.com/pinard/Recode/commit/22aea3f9373590567736c197125babe93caab412
(In reply to David Heidelberger (okias) from comment #19) > Could you reopen it? After this change, it work well even with 1.14. > > Thank you No, see comment 8, it's already fixed, although slightly in different way, and also good thing it avoid to introduce another patch. it's really a bug should be fixed in upstream side. so let's just hope upstream will roll out a new release, and eventually solved.
I asked François Pinard if is possible to release some _alpha or _beta. Waiting for reply (last code change is motnh ago, last release 6 years ago - v3.7-beta2)
