| Summary: | emerge with distcc fails with "can't find a register in class `BREG' while reloading `asm'" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Yang Zhao <yang> |
| Component: | Current packages | Assignee: | Lisa Seelye (RETIRED) <lisa> |
| Status: | VERIFIED NEEDINFO | ||
| Severity: | minor | CC: | base-system, trey |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Yang Zhao
2006-04-11 10:19:36 UTC
This fails because 'distcc-config --install' creates symlinks which don't give enough information for cross-compiled tool chains. http://www.gentoo.org/doc/en/cross-compiling-distcc.xml describes a work-around which probably ought to replace the creation of the non-CHOST symlinks in distcc-config. (In reply to comment #1) > http://www.gentoo.org/doc/en/cross-compiling-distcc.xml describes a work-around Thanks for that. However, I should note that I screwed up a little in the original summary: both systems are i686, but one is pentium-m and the other pentium3. So, there doesn't seem to be any actual "cross compiling", but the distcc client is choking on unknown assembly optimizations. It seems you have some other problem, then. Perhaps the register allocation changes for non-hardened vs. hardened platforms. The 'equery uses gcc' output for both systems might prove useful. As far as I can tell, distcc and CHOST don't have any way to show the hardened status, or to choose a compiler based upon it. Occurs with glibc also. I'm changing bug summary to a more generic one. *snip* gconv_cache.c: In function `__gconv_load_cache': gconv_cache.c:75: error: can't find a register in class `BREG' while reloading `asm' gconv_cache.c:112: error: can't find a register in class `BREG' while reloading `asm' distcc[14790] ERROR: compile gconv_cache.c on sui/1 failed make[2]: *** [/var/tmp/portage/glibc-2.3.6-r3/work/build-default-i686-pc-linux-gnu-nptl/iconv/gconv_cache.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.6-r3/work/glibc-2.3.6/iconv' make[1]: *** [iconv/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.6-r3/work/glibc-2.3.6' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.3.6-r3 failed. !!! Function toolchain-glibc_src_compile, Line 258, Exitcode 2 !!! make for default failed !!! If you need support, post the topmost build error, NOT this status message. Please disable --fomit-frame-pointer and try again:
-fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't
need one. This avoids the instructions to save, set up and restore
frame pointers; it also makes an extra register available in many
functions. It also makes debugging impossible on some machines.
You may also want to disable sse2 USE flag since P3s don't offer that.
Curious: is this clearly a deficiency of distcc or is there an actual bug that's happening? The pentium-m system has had everything in it compiled using distcc, and the problem only occurs in a few select packages. It's trivial to work around, so I'm not worried too much about it, but it would be nice to see it fixed. As for the --fomit-frame-pointer test, I'll try doing that on one of the smaller affected packages later this week. I've had this BREG thing come up before even when not using distcc. It leeds me to believe there's something funky going on somewhere. See bug 43964 for this showing up without distcc being used. It could be that on your volunteer it may be using the hardened-gcc? nothing heard since last comment Sorry for the lack of updates on this. I actually no longer have the hardware to try and reproduce problem on (laptop powersupply fried), so I'm going to go ahead and close it. |
