Hello, I stumbled upon a weird bug, probably autoconf related. Also see bug 479372 for more details. Maybe this is automake and not autoconf bug, I'm not sure, issue is comlicated. When building app-text/docbook2X-0.8.8-r4 usually autoconf works fine, but sometimes it generates different configure script on the same host with the same settings. This "sometimes" is somewhat rare: for me error occured on 60-th run of emerge in the following test: i=0; while FEATUREs="-ccache" emerge --quiet-build --quiet -1 docbook2X; do i=$(++i); echo "^--> attempt = $i"; done As one can see from bug 479372, other people also have this problem. Comparison of "good" and "bad" configure scripts shows, that problem of the build failure is that @am__isrc@ template is not substituted by "bad" configure, though there are other differences between scripts, so in case of error one have command: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.@am__isrc@ ... instead of x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/app-text/docbook2X-0.8.8-r4/work/docbook2X-0.8.8/utf8tran ... See attached data for more details. Also I'll attach full package dirs from /var/tmp of good and bad cases in case you need some additional data.
Created attachment 389540 [details, diff] configure.diff Difference between normal and malformed configure scripts.
Created attachment 389542 [details] docbook2X-0.8.8-r4-good.tar.xz Full build tree of normal build process.
Created attachment 389544 [details] docbook2X-0.8.8-r4-bad.tar.xz Full build tree of the broken build.
Created attachment 389546 [details] emerge.info emerge --info output on the system where builds above were done.
Created attachment 389548 [details] emerge.info-2 emerge --info output on another system where the same fail had happened.
i vaguely recall another bug tracking the idea that autotools' cache in the autom4te subdir sometimes got out of sync, but i can't find it now
(In reply to SpanKY from comment #6) > i vaguely recall another bug tracking the idea that autotools' cache in the > autom4te subdir sometimes got out of sync, but i can't find it now Do you mean apr problem with libtool 2.4.3 (bug 527506) ?
docbook2X don't have libtool, though it looks like autom4te cache indeed goes rouge. I'll test with patched autotools.eclass.
I confirm that autotools.eclass patch https://bugs.gentoo.org/attachment.cgi?id=389294 from bug 527506 fixes this issue. (I made a 1066 runs of emerge process without this issue.) Will wait for this fix to be applied for autotools.eclass.
(In reply to Rafał Mużyło from comment #7) no, one filed much longer ago than that. it involved weird race conditions in /var/tmp/portage (maybe due to tmpfs) where sometimes the cache wasn't up-to-date. i want to say it was filed by jlec@, but i really can't remember enough details to locate it.
I have this bug on a host where /var/tmp/ resides on ext4, so this is not a tmpfs issue.
autotools.eclass is fixed now (see bug 527506), so closing this issue.
