Created attachment 314947 [details] Patch between original and hacked autotools.eclass Bug reports 417355 (sgml-common) and 419741 (mono-tools), also libatomic-ops (not yet reported) are prone to failed ebuilds which result in a message like this: configure.in:4: version mismatch. This is Automake 1.11.5, configure.in:4: but the definition used by this AM_INIT_AUTOMAKE configure.in:4: comes from Automake 1.10.1. You should recreate configure.in:4: aclocal.m4 with aclocal and run automake again. I traced the problem to autotools.eclass as follows: The client ebuild executes src_unpack or src_prepare. One of these calls eautoreconf() which is defined at line 146 in autotools.eclass I am reporting against this version: # $Header: /var/cvsroot/gentoo-x86/eclass/autotools.eclass,v 1.146 2012/06/07 06:00:05 vapier Exp $ At line 183 a call is made to _at_uses_glibgettest which eventually results in a call to autotools_check_macro. Later in eautoreconf, at line 191, eaclocal is called. eaclocal is defined at line 283. At line 285 this call is made: autotools_run_tool --at-m4flags aclocal "$@" $(eaclocal_amflags) autotools_run_tool is defined at line 421. It reacts to m4flags and eventually calls autotools_check_macro, this is the second time that autotools_check_macro is called. autotools_check_macro is defined at line 494. As described above it is invoked in two passes (well, as far as autoconf is concerned, it may be called elsewhere as well). This macro has a strategy for dealing with multiple invocations: it writes its output to a trace_file. The problem that I have found happens at line 500 which contains this: if [[ ! -e ${trace_file} ]] || [[ aclocal.m4 -nt ${trace_file} ]] ; then When the client ebuild works correctly, the second test... [[ aclocal.m4 -nt ${trace_file} ]] ... is true and the following line is executed where upon autoconf is called (so under normal circumstances, it gets called twice at this point, it gets called later again). However, depending on timing of events in the first pass, sometimes aclocal.mt and the trace_file both get _the same time stamp_. The test fails. autoconf is not called a second time. When automake is run by the client ebuild, it finds a version mismatch and reports this: configure.in:4: comes from Automake 1.10.1. You should recreate configure.in:4: aclocal.m4 with aclocal and run automake again. I have hacked a temporary solution by creating an artificial mtime difference between aclocal.m4 and the trace_file. A patch is attached. Actually, my hack is hard to understand; it looks wrong. The -nt (newer than) test is appropriate, we only want autoconf to be called when something has happened to aclocal.m4 since the trace_file was created. Why does a 1s time difference in apparently the wrong sense resolve the bug? Perhaps it does something for subsequent calls to eautoconf - of which there are a few. I hope my findings point to a better solution.
I see this error often with PORTAGE_TMPDIR on tmpfs.
I confirm i have this bug and i'm using PORTAGE_TMPDIR on tmpfs
I have to confirm this promlem on 64bit (Intel Xeon) _without_ using tempfs: # equery list app-text/sgml-common [IP-] [ ] app-text/sgml-common-0.6.3-r5:0 # equery list sys-boot/grub [IP-] [ ] sys-boot/grub-0.97-r10:0 # equery list app-text/a2ps [IP-] [ ] app-text/a2ps-4.14-r2:0 After an emerge -e, at least these three failed. Iteratively re-emerging (--oneshot) these (each about 10 times), they sometimes compile flawlessly, somtimes fail.
Instead of playing with the time stamp on the trace file, maybe the test just needs to be changed to this: [[ ! aclocal.m4 -ot ${trace_file} ]]
I ran into this when installing (just a few days ago) gentoo on a new fresh system. emerge -e world failed on random packages this way. I applied patch and emerged almost all packages out of 420 (it's still compiling). Before that I couldnt manage to get it done without fail in one go. It's a pity that this bug affects fresh installs. I didnt use tmpfs but I have plenty of ram. I can provide more details if requested.
+ 20 Sep 2012; Tomáš Chvátal <scarabeus@gentoo.org> autotools.eclass: + Be more strict about eautoreconfig on aclocal.m4. Fixes bug#424763 and + bug#420631. +
I'm sorry, but bug seems to be alive. I have fully rebuild two worlds (emerge -evabDuN world) now (x86 and amd64) and before appling patch by Branko I have automake errors in multiple random packages. After appling patch everything (~1500 packages) builds ok.
Created attachment 336168 [details, diff] autotools.patch Here, you could try this cyberbat. It doesn't delay the build if there's no need, as discussed on in #-dev-help.
(In reply to comment #8) > Created attachment 336168 [details, diff] [details, diff] > autotools.patch > > Here, you could try this cyberbat. It doesn't delay the build if there's no > need, as discussed on in #-dev-help. Seems to work ok.
