Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 420631 - autotools.eclass sporadically fails to call autoconf which causes automake errors
Summary: autotools.eclass sporadically fails to call autoconf which causes automake er...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Blocks: 417355
  Show dependency tree
Reported: 2012-06-11 06:02 UTC by Branko
Modified: 2013-10-06 15:31 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---

Patch between original and hacked autotools.eclass (autotools.patch,411 bytes, text/plain)
2012-06-11 06:02 UTC, Branko
autotools.patch (file_420631.txt,1.60 KB, patch)
2013-01-19 21:07 UTC, Steve L
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Branko 2012-06-11 06:02:54 UTC
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: version mismatch.  This is Automake 1.11.5, but the definition used by this AM_INIT_AUTOMAKE comes from Automake 1.10.1.  You should recreate 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 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: comes from Automake 1.10.1.  You should recreate 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.
Comment 1 Justin Lecher gentoo-dev 2012-06-15 14:04:01 UTC
I see this error often with PORTAGE_TMPDIR on tmpfs.
Comment 2 predhomme.p 2012-06-19 07:21:13 UTC
I confirm i have this bug and i'm using PORTAGE_TMPDIR on tmpfs
Comment 3 Manfred Knick 2012-06-28 10:25:52 UTC
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.
Comment 4 Mike Gilbert gentoo-dev 2012-09-10 02:29:10 UTC
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} ]]
Comment 5 Lukasz Ligowski 2012-09-11 08:45:10 UTC
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.
Comment 6 Tomáš Chvátal (RETIRED) gentoo-dev 2012-09-20 18:05:07 UTC
+  20 Sep 2012; Tomáš Chvátal <> autotools.eclass:
+  Be more strict about eautoreconfig on aclocal.m4. Fixes bug#424763 and
+  bug#420631.
Comment 7 cyberbat 2013-01-16 13:16:01 UTC
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.
Comment 8 Steve L 2013-01-19 21:07:18 UTC
Created attachment 336168 [details, diff]

Here, you could try this cyberbat. It doesn't delay the build if there's no need, as discussed on in #-dev-help.
Comment 9 cyberbat 2013-01-21 11:43:07 UTC
(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.