| Summary: | =sys-devel/gcc-4.8.4: parallel build with 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-PR61899.patch | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Thibaud CANALE <thican> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | abandonedaccountubdprczb8hs, jbowler, mlischka, theism |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log (gzip format)
emerge --info build.log.gz sys-devel/gcc-4.8.4's build.log.gz on samus, compiled with sys-devel/gcc-4.9.2 and without parallel build. emerge --info '=sys-devel/gcc-4.8.4' on samus sys-devel/gcc-4.8.4's build.log.gz on my friend's system. emerge --info '=sys-devel/gcc-4.8.4' on my friend's system |
||
|
Description
Thibaud CANALE
2015-04-02 20:11:04 UTC
Created attachment 400420 [details]
emerge --info
Do it work if you disable distcc (In reply to Magnus Granberg from comment #2) > Do it work if you disable distcc Already tried, it didn't. Created attachment 400696 [details]
build.log.gz
New day, new set of errors:
During compilation, segmentation faults appeared, multiple times, with this output (3 lines in dmesg):
[ +X.XXXXXX] cc1plus[23383]: segfault at 3b03defd038 ip 0000000000dd56cf sp 00
000398571bd3c0 error 4 in cc1plus[400000+e09000]
[ +0.000015] grsec: Segmentation fault occurred at 000003a67fc96038 in /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc/cc1plus[cc1plus:20245] uid/euid:250/250 gid/egid:250/250, parent /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc/xgcc[xgcc:20244] uid/euid:250/250 gid/egid:250/250
[ +0.000010] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc/cc1plus[cc1plus:20245] uid/euid:250/250 gid/egid:250/250, parent /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc/xgcc[xgcc:20244] uid/euid:250/250 gid/egid:250/250
I tried to check the relation with the log, but I didn't find one by myself.
But those segmentation faults are not the reasons sys-devel/gcc-4.8.4 fails to compile; as you can see in the attached log file, at the end of the file, this output:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DEFAULT_PIE_SSP -fno-PIE -DHOST_GENERATOR_FILE -m64 -march=corei7-avx -O2 -pipe -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wno-error -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libdecnumber/bid -I../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libbacktrace gengtype-lex.c -o gengtype-lex.o
gengtype-lex.c:1:21: fatal error: bconfig.h: No such file or directory
#include "bconfig.h"
^
compilation terminated.
I have no idea why I don't have the same errors, even with the same PATCH_VER="1.4" in the ebuild file, but this is still related to the file "gengtype".
Thanks for support.
(In reply to Thibaud "thican" CANALE from comment #4) if your kernel config is causing gcc to crash, we're not really going to look into the issue further (In reply to SpanKY from comment #5) > (In reply to Thibaud "thican" CANALE from comment #4) > > if your kernel config is causing gcc to crash, we're not really going to > look into the issue further Based on which information? Does a missing header file is because of my kernel? I don't think so. (In reply to Thibaud "thican" CANALE from comment #6) if you can't envision a scenario where killing compiler operations would break the build in interesting ways, then you'll have to be more creative. fix your kernel behavior and then we'll look. (In reply to SpanKY from comment #7) > fix your kernel behavior and then we'll look. Done. My modo: “don't fix it if it ain't broken.” Well, I will now be serious between the two of us: except if you want trying to play fool with me and throwing some bad reasons without tell what is wrong, I can't work with you. (In reply to SpanKY from comment #7) > if you can't envision a scenario where killing compiler operations would > break the build in interesting ways, then you'll have to be more creative. I really don't understand what you want to say here. Do you think the segmentation fault of `cc1plus` is because of my kernel? You are maybe right, or maybe wrong, and I though about this too, but I don't see how. Yes, I don't have a lot of knowledges in GRsec/PaX features, and I would like to avoid breaking my system by tring to disable it (except recompiling another kernel); but unfortunately, your attitude is not helping (and even worse). (In reply to Thibaud "thican" CANALE from comment #9) > > Yes, I don't have a lot of knowledges in GRsec/PaX features, and I would > like to avoid breaking my system by tring to disable it (except recompiling > another kernel); but unfortunately, your attitude is not helping (and even > worse). 1) It looks to me like grsec/pax is not killing but reporting the seg fault in cc1plus. However, I would feel a lot better if you could reproduce this on a vanilla kernel. 2) I don't get comment #0 at all. And I don't know why that error magically went away. Something on your system looks broken. 3) However, the error in comment #4 makes me worry a bit more because I wonder if 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-PR61899.patch broke something. In particular this line: -gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) which was added to fix a parallel build failure is removed. Look at bug #463796 and 93_all_4.8.0_gengtype-lex_parallel_build.patch in 4.7.4 and 4.8.4 patchsets. (In reply to Thibaud "thican" CANALE from comment #9) > Well, I will now be serious between the two of us: except if you want trying > to play fool with me and throwing some bad reasons without tell what is > wrong, I can't work with you. Relax. No one is playing any games. The point is if you build gcc under a highly modified kernel like grsec/pax, then wierd things can happen. eg. we have to relax randmmap on cc1 and cc1plus otherwise things blow up. In fact, while you're at it, can you tell us what you get for paxctl-ng -v /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1* Hello Anthony, thanks for your help. (In reply to Anthony Basile from comment #10) > (In reply to Thibaud "thican" CANALE from comment #9) > > Yes, I don't have a lot of knowledges in GRsec/PaX features, and I would > > like to avoid breaking my system by tring to disable it (except recompiling > > another kernel); but unfortunately, your attitude is not helping (and even > > worse). > > 1) It looks to me like grsec/pax is not killing but reporting the seg fault > in cc1plus. However, I would feel a lot better if you could reproduce this > on a vanilla kernel. Should I have to compile my current version of gcc, the version 4.8.3, with the "vanilla" USE flag, or could I use the entry "x86_64-pc-linux-gnu-4.8.3-vanilla" in the `gcc-config --list-profiles`? > 2) I don't get comment #0 at all. And I don't know why that error magically > went away. Something on your system looks broken. Well, I first tought it was related to this other bug report, but it is actually not, so my comment #0 is now irrelevant. > 3) However, the error in comment #4 makes me worry a bit more because I > wonder if 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-PR61899.patch > broke something. In particular this line: > > -gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H) > > which was added to fix a parallel build failure is removed. Look at bug > #463796 and 93_all_4.8.0_gengtype-lex_parallel_build.patch in 4.7.4 and > 4.8.4 patchsets. Okay, I will look into more further later, because it is already late under my timezone. :-) I'll keep this bugreport update. > (In reply to Thibaud "thican" CANALE from comment #9) > > Well, I will now be serious between the two of us: except if you want trying > > to play fool with me and throwing some bad reasons without tell what is > > wrong, I can't work with you. > > Relax. No one is playing any games. Sorry, I give you my apologies then. Because it took me time to do those reports, trying multiple rebuilds, checking USE flag and libraries consistency or any obvious mistakes before sending my reports, therefore it is kind of upsetting me when it got blow away… > The point is if you build gcc under a > highly modified kernel like grsec/pax, then wierd things can happen. eg. we > have to relax randmmap on cc1 and cc1plus otherwise things blow up. In > fact, while you're at it, can you tell us what you get for > > paxctl-ng -v /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1* Here we go: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -e-r- XATTR_PAX : not found /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/cc1plus: open(O_RDWR) failed: cannot change PT_PAX flags PT_PAX : -e-r- XATTR_PAX : not found Just for information, next stable kernel I will disable support of PT_PAX for the benefit of XATTR_PAX. Thanks for support. (In reply to Thibaud "thican" CANALE from comment #9) if you think we have so few bugs that we can waste time tracking down phantom bugs that exist only on broken boxes, you're highly mistaken. requesting you get your system into a sane state *before* we spend time is extremely reasonable. if you want to insist your system is perfectly fine, then we can simply leave this bug open for a year and then punt it as obsolete when gcc-4.9 goes stable. (In reply to SpanKY from comment #12) I am starting to ignoring you, Mike. And stop those comments, you are polluting this report. (In reply to Thibaud "thican" CANALE from comment #13) here's a protip: you probably shouldn't tell the only active toolchain maintainer to piss off. but maybe you'll get lucky and Anthony can make sense out of your garbage. I have completely same problem! Hardened profile, but not kernel (no grsec/pax patch). With patch "93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-R61899.patch", compile phase failed with following errors:
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:0:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:500:34: error: declaration of C function ‘const char* strsignal(int)’ conflicts with
extern const char *strsignal (int);
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:205,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/usr/include/string.h:563:14: error: previous declaration ‘char* strsignal(int)’ here
extern char *strsignal (int __sig) __THROW;
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:645:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../include/libiberty.h:110:36: error: new declaration ‘char* basename(const char*)’
extern char *basename (const char *);
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:205,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/usr/include/string.h:600:26: error: ambiguates old declaration ‘const char* basename(const char*)’
extern "C++" const char *basename (const char *__filename)
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:0:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:289:56: error: ‘CHAR_BIT’ was not declared in this scope
? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:290:44: note: in expansion of macro ‘INTTYPE_MINIMUM’
#define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:294:20: note: in expansion of macro ‘INTTYPE_MAXIMUM’
# define UCHAR_MAX INTTYPE_MAXIMUM (unsigned char)
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.h:455:23: note: in expansion of macro ‘UCHAR_MAX’
CHAR_TOKEN_OFFSET = UCHAR_MAX + 1,
^
Makefile:1070: recipe for target 'gengtype.o' failed
make[3]: *** [gengtype.o] Error 1
With 'EPATCH_EXCLUDE+=" 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-PR61899.patch"' line in .ebuild, compilation succeeded without problems.
(In reply to Jiří Moravec from comment #15) > I have completely same problem! Hardened profile, but not kernel (no > grsec/pax patch). With patch > "93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-R61899.patch", compile > phase failed with following errors: > Something is going on here but I can't put my finger on it or reproduce it. I'm convinced it has nothing to do with the hardened kernel, but may have something to do with toolchain hardening patches + parallel build. If anyone is willing to test, leave the 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-R61899.patch in there and try building with MAKEOPTS=-j1 and =-j9 (or whatever number of cores you have +1). Let's see if this is triggered by parallel builds. I'd try myself, but I just can't hit it. Hello everyone, I tried to compile it, disabling distcc and setting MAKEOPTS="--jobs 1": failure, with the same error. But, with "vanilla" USE flag (I know about the fact that hardened features are disabled): success. Here the differences between normal and no-parallel configuration: make -j17 -l4 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' STAGE1_CFLAGS= LIBPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4 'BOOT_CFLAGS=-m64 -march=corei7-avx -O2 -pipe' bootstrap-lean make --jobs 1 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' STAGE1_CFLAGS= LIBPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4 'BOOT_CFLAGS=-m64 -march=corei7-avx -O2 -pipe' bootstrap-lean Therefore, it's not related to my GRsec|PaX kernel (quoting) "garbage" of mine, because the failure in compilation occurs on one of my other Hardened Gentoo system (named humanoide FYI), which has not those features in kernel. (no segmentation fault on humanoide about /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc/cc1plus). To be clear, it's obviously not related to the kernel. Therefore, of what I understand, and as said Jiří Moravec comment 15, this seams to be related with a patch. I may provide more informations, just ask me what you want to do, and I will return. Thanks for support. make.conf: MAKEOPTS="-j 4" EMERGE_DEFAULT_OPTS="--keep-going --ask-enter-invalid --quiet-build=y --quiet-fail=y --jobs=4 --load-average=4.4 --autounmask-keep-masks" ---------------------------------------------------------------- MAKEOPTS="-j4 -l4" USE="-cxx -gcj" emerge -v1 --jobs=4 --load-average=4 --buildpkgonly =sys-devel/gcc-4.8.4-r4:4.8::jim-private FAILED. MAKEOPTS="-j1" USE="-cxx -gcj" emerge -v1 --jobs=1 --buildpkgonly =sys-devel/gcc-4.8.4-r0:4.8::jim-private SUCCEEDED! Both overlay ebuilds are copies of the stock ebuild. (In reply to Jiří Moravec from comment #18) > make.conf: > MAKEOPTS="-j 4" > EMERGE_DEFAULT_OPTS="--keep-going --ask-enter-invalid --quiet-build=y > --quiet-fail=y --jobs=4 --load-average=4.4 --autounmask-keep-masks" > ---------------------------------------------------------------- > > MAKEOPTS="-j4 -l4" USE="-cxx -gcj" emerge -v1 --jobs=4 --load-average=4 > --buildpkgonly =sys-devel/gcc-4.8.4-r4:4.8::jim-private FAILED. > > MAKEOPTS="-j1" USE="-cxx -gcj" emerge -v1 --jobs=1 --buildpkgonly > =sys-devel/gcc-4.8.4-r0:4.8::jim-private SUCCEEDED! > > Both overlay ebuilds are copies of the stock ebuild. There may be more than just an ebuild in the overlay, eg an outdated eclass. Can you test with the tree version and no overlays. Two days ago every attempt (~5) to compile gcc-4.8.4 failed with a same errors. Even today one attempt failed and right now this problem completely disappeared and everything is alright... :-() I really don't understand it. This is scary. And in my testing overlay jim-private are no eclasses at all... Hello Anthony (In reply to Anthony Basile from comment #16) > If anyone is willing to test, leave the > 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-R61899.patch in there and > try building with MAKEOPTS=-j1 and =-j9 (or whatever number of cores you > have +1). Let's see if this is triggered by parallel builds. I'd try > myself, but I just can't hit it. As you requested, I retried with -j1 (and without distcc), on a new kernel (i.e without GRSec/PaX, for Mike's pleasure), it finally works. Do I have to mention I built this with the version 4.9.2 of gcc? So, from sys-devel/gcc-4.9.2 using -j1, it works, but do you want me to test my brand new 4.8.4 version to recompile itself, with or without parallel build, or is it pointless? Anyway, please find as attachment my build.log, and a new emerge --info of my main system (a desktop machine named megaman). But this is not over, because of friend got the same but on a NOT hardened system! Don't worry, here come the informations. Thanks for support. Created attachment 401094 [details]
sys-devel/gcc-4.8.4's build.log.gz on samus, compiled with sys-devel/gcc-4.9.2 and without parallel build.
Success compilation without parallel build, on an hardened system without GRsec|PaX.
Created attachment 401096 [details]
emerge --info '=sys-devel/gcc-4.8.4' on samus
New emerge --info, principal changements are:
- new kernel using current unstable 3.19.3-hardened-r1, without GRsec|PaX
- cohabitation of gcc-4.9.2 (default is still branch 4.8).
Created attachment 401098 [details]
sys-devel/gcc-4.8.4's build.log.gz on my friend's system.
Failed compilation, compiled with sys-devel/gcc-4.8.3 with "normal" build, on a NOT hardened system!
Created attachment 401100 [details]
emerge --info '=sys-devel/gcc-4.8.4' on my friend's system
"emerge --info" from a not hardened system, using default provider's kernel with grsec features (but no segmentation fault of gcc's compilation during process).
(In reply to Jiří Moravec from comment #20) > Two days ago every attempt (~5) to compile gcc-4.8.4 failed with a same > errors. Even today one attempt failed and right now this problem completely > disappeared and everything is alright... :-() I really don't understand it. > This is scary. > > And in my testing overlay jim-private are no eclasses at all... There is too much conflicting info and I can't reproduce this. As a parallel build problem, it can be intermittent and so I'm just getting lucky and you're not. All I have that is concrete is that in the 4.7 series, Ryan backported 93_all_4.8.0_gengtype-lex_parallel_build.patch discussed at https://gcc.gnu.org/ml/gcc-patches/2012-11/msg01682.html to fix parallel building of gengtype-lex.c which was failing to find bconfig.h. In the 4.8 and 4.9 Mike backported 93_all_gcc-4.8-config.h-bconfig.h-parallel-PR57125-PR61899.patch discussed at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03092.html This is a more conprehensive fix to the same problem. This bug reportsuggests the PR57125-PR61899.patch isn't working, and yet switching to -j1 didn't fix it, so now I'm just confused. I'd love to see step by step to reproduce from a fresh stage3 tarball on a vanilla kernel. Hello everyone, (In reply to Anthony Basile from comment #26) > This bug reportsuggests the PR57125-PR61899.patch isn't working, and yet > switching to -j1 didn't fix it, so now I'm just confused. For me, on my three systems and even on my friend's one, switching to -j1 compiled successfully. Those are four heterogenes systems, desktop computer, little server with 2GB of RAM and atom, big server, and even a laptop, 3 with hardened, one without it, all got the same error, and the resolution was "-j1". > I'd love to see step by step to reproduce from a fresh stage3 tarball on a > vanilla kernel. I could even try on my x86_x32 hardened desktop system, see if this occurs aswell … if you want (and if I have time). Thanks for support. *** Bug 538422 has been marked as a duplicate of this bug. *** (In reply to Thibaud "thican" CANALE from comment #27) > Hello everyone, > > (In reply to Anthony Basile from comment #26) > > This bug reportsuggests the PR57125-PR61899.patch isn't working, and yet > > switching to -j1 didn't fix it, so now I'm just confused. Ah maybe I misunderstood. So you have a case where -j1 works but -jX with X>1 doesn't work? And its reproduceable? (In reply to Anthony Basile from comment #29) > (In reply to Thibaud "thican" CANALE from comment #27) > > Hello everyone, > > > > (In reply to Anthony Basile from comment #26) > > > This bug reportsuggests the PR57125-PR61899.patch isn't working, and yet > > > switching to -j1 didn't fix it, so now I'm just confused. > > Ah maybe I misunderstood. So you have a case where -j1 works but -jX with > X>1 doesn't work? And its reproduceable? Yes, I do, and yes it is reproduceable, I've just done it with my system (named megaman, the first one I create this bug for). I noticed a new patch version in the ebuild, and those previous bug reports about an error which seams to be related, bug 487398. Therefore, I think I should put this bug as resolve duplicate of bug 487398. Don't you agree? (In reply to Anthony Basile from comment #29) > And its reproduceable? Building sys-devel/gcc-4.8.4 with gcc-4.8.3, portage tree synced few hours ago. With MAKEOPTS="-j3 ..." build fails (repeatedly), switching to -j1 solves the mentioned problem. Using gentoo-sources-3.14.14 (symlink -build -deblob -experimental), default/linux/amd64/13.0/desktop/kde profile, x86_64 arch. However, few days ago, my another desktop with similar configuration updated gcc-4.8.3 -> gcc-4.8.4 without any problem. Seems Anthony was right: it's about (not) being lucky. (In reply to Ondřej Kajínek from comment #32) > However, few days ago, my another desktop with similar configuration updated > gcc-4.8.3 -> gcc-4.8.4 without any problem. Seems Anthony was right: it's > about (not) being lucky. Obviously there is some deterministic reason but we just can't put our finger on it. We do know its a parallel build failure related to that patch. But I've run `make -jX` for X=1 through 33 (not every one) and never hit it. I can't admit to understanding this patch but the old one (to address the same problem) was pretty clear about what was going on with bconfig.h. (In reply to Anthony Basile from comment #33) > (In reply to Ondřej Kajínek from comment #32) > > > However, few days ago, my another desktop with similar configuration updated > > gcc-4.8.3 -> gcc-4.8.4 without any problem. Seems Anthony was right: it's > > about (not) being lucky. > > Obviously there is some deterministic reason but we just can't put our > finger on it. We do know its a parallel build failure related to that > patch. But I've run `make -jX` for X=1 through 33 (not every one) and never > hit it. I can't admit to understanding this patch but the old one (to > address the same problem) was pretty clear about what was going on with > bconfig.h. For me, I have found something : the "--load-average" option from make(1). My computers are most of them under constant heavy load, and the one which are not don't have a lot of power (little servers using distcc for example). Before, my MAKEOPTS in my make.conf was "--jobs=9 --load-average=8" on my server (named megaman to be clear), and like most of my other system. From make(1), I noticed this in the description of this option: “With no argument, removes a previous load limit.” the whole description: -l [load], --load-average[=load] Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a floating-point number). With no argument, removes a previous load limit. Therefore, in my new MAKEOPTS variable, I removed the "=8", to remove the limit; it works. It works aswell if I do not specify --load-average at all. My last test is, on my system named megaman with gcc version 4.8.4, which I did multiple times just by changing the content of the MAKEOPTS variable: ebuild /usr/portage/sys-devel/gcc/gcc-4.8.4.ebuild clean fetch unpack compile install Step to reproduce: 1) In your MAKEOPTS from your make.conf file, specify a load-average limit _with_ a value (not sure about that, but put your system on heavy load during compilation), 2) compile gcc, 3) failure. This is a success if you do not specify a load-average limit, or if you disable it (by writing "--load-average" without a value). I'm encountering either of the build failures posted in this bug on gentoo-sources-4.0.4 with 4.9.2 being my main system GCC. Removing my "--load-average" option from MAKEOPTS allows me to build without any issues. I can confirm the same thing: with MAKEOPTS="-j3 -l1" I consistently saw the reported build failure, with MAKEOPTS="-j1" the build succeeds. The repro may require a suitably underpowered system. Mine is a Raspberry Pi model B with 256MByte of DRAM (i.e. the original Model B) running distcc. My guess is that both a slow host CPU and distcc will be required; this combination results in parallel runs of the preprocessor on the host each of which is quite slow. (The whole build takes about 18 hours.) I had the same problem trying to compile gcc-4.8.4 in a full upgrade in parallel with other packages. Seeming random fails (most likely due to the successful compilation of the smaller packages and the load changing on each attempt). When I installed gcc-4.8.4 oneshot on it's own single threaded with no load averaging it worked fine: emerge --oneshot =sys-devel/gcc-4.8.4 --jobs=1 --load-average Also happens with gcc-4.8.5 (armv6a, distcc) (In reply to John Bowler from comment #38) > Also happens with gcc-4.8.5 (armv6a, distcc) Yes, I would be very surprised if it didn't, but its good to document it. This is what I'm getting with catalyst while building amd64 stage1 (non hardened):
/bin/bash /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../move-if-change tmp-mlib.h multilib.h
echo timestamp > s-mlib
lsf="/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/cp/lang-specs.h /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/lto/lang-specs.h"; for f in $lsf; do \
echo "#include \"$f\""; \
done | sed 's|/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/||' > tmp-specs.h
/bin/bash /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../move-if-change tmp-specs.h specs.h
echo timestamp > s-specs
echo "/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -DEFAULT_SSP -m64 -O2 -pipe -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrit
e-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc " > checksum-options.tmp \
&& /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../move-if-change checksum-options.tmp checksum-options
gawk -f /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/config/i386/i386-builtin-types.awk /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/config/i386/i386-builtin-types.def > tmp-bt.inc
/bin/bash /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../move-if-change tmp-bt.inc i386-builtin-types.inc
echo timestamp > s-i386-bt
cp /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gcc-ar.c gcc-nm.c
cp /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gcc-ar.c gcc-ranlib.c
/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DEFAULT_SSP -DHOST_GENERATOR_FILE -m64 -O2 -pipe -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wn
o-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libdecnumber/bid -I../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../libbacktrace /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c -o gengtype.o
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:0:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:500:34: error: declaration of C function 'const char* strsignal(int)' conflicts with
extern const char *strsignal (int);
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:205,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/usr/include/string.h:563:14: error: previous declaration 'char* strsignal(int)' here
extern char *strsignal (int __sig) __THROW;
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:645:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)'
extern char *basename (const char *);
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:205,
from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:
/usr/include/string.h:600:26: error: ambiguates old declaration 'const char* basename(const char*)'
extern "C++" const char *basename (const char *__filename)
^
In file included from /var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.c:26:0:
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:289:56: error: 'CHAR_BIT' was not declared in this scope
? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:290:44: note: in expansion of macro 'INTTYPE_MINIMUM'
#define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/system.h:294:20: note: in expansion of macro 'INTTYPE_MAXIMUM'
# define UCHAR_MAX INTTYPE_MAXIMUM (unsigned char)
^
/var/tmp/portage/sys-devel/gcc-4.8.4/work/gcc-4.8.4/gcc/gengtype.h:455:23: note: in expansion of macro 'UCHAR_MAX'
CHAR_TOKEN_OFFSET = UCHAR_MAX + 1,
^
Makefile:1070: recipe for target 'gengtype.o' failed
make[3]: *** [gengtype.o] Error 1
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.8.4/work/build/gcc'
Makefile:4231: recipe for target 'all-stage3-gcc' failed
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.8.4/work/build'
Makefile:16391: recipe for target 'stage3-bubble' failed
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-4.8.4/work/build'
Makefile:16465: recipe for target 'bootstrap-lean' failed
make: *** [bootstrap-lean] Error 2
* ERROR: sys-devel/gcc-4.8.4::gentoo failed (compile phase):
* emake failed
I'm also getting this error for the hardened stage3, hardened nomultilib stage1 and nomultilib stage3 (non-hardened).
(In reply to Jorge Manuel B. S. Vicetto from comment #40) > This is what I'm getting with catalyst while building amd64 stage1 (non > hardened): > I'm seeing the same result building on i686 with a non-hardened kernel/toolchain, parallel make, and a load average option. The removal of the load-average options suggested above resolved the problem. However, I left parallel make (-j4) enabled. *** This bug has been marked as a duplicate of bug 487398 *** (In reply to SpanKY from comment #14) Anthony: btw, i didn't mean this to disparage your contributions. you're not listed in the toolchain herd although you have certainly helped out of late. (In reply to SpanKY from comment #43) > (In reply to SpanKY from comment #14) > > Anthony: btw, i didn't mean this to disparage your contributions. you're > not listed in the toolchain herd although you have certainly helped out of > late. Much appreciated, but I never felt disparaged. I'm happy to pick off the low lying fruits if it frees up time for others who are better at the heavy lifting. |
