| Summary: | RESTRICT=nodistcc feature request | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Simon Matthews <simon+bugzilla> |
| Component: | Conceptual/Abstract Ideas | Assignee: | Portage team <dev-portage> |
| Status: | VERIFIED LATER | ||
| Severity: | enhancement | CC: | akf.hofer, eradicator, sound, znmeb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=669978 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Log of alsa-driver attempted compile
"emerge -v info" after failed emerge of alsa-driver ebuild.sh-nodistcc.patch |
||
|
Description
Simon Matthews
2005-02-05 11:49:38 UTC
Created attachment 50507 [details]
Log of alsa-driver attempted compile
I have a similar problem with compiling "alsa-driver". The error message looks
different from the original poster's, but it appears to be related to "distcc"
and parallel makes.
Created attachment 50508 [details]
"emerge -v info" after failed emerge of alsa-driver
I've got something that looks similar, though I got a different error message. I've attached the log and the "emerge info" printout. I'm definitely using "distcc". I'm re-running the emerge with "MAKEOPTS=-j1" to see if it works that way. Well ... doesn't work even with MAKEOPTS="-j1" and distcc turned off. After looking at the logs, it looks like an error in the source. So I'm going to open a new bug against alsa-driver-1.0.8_rc1. I'll flag this one as related. Over and out Ed Borasky Created attachment 50702 [details, diff]
ebuild.sh-nodistcc.patch
patch to current cvs to add RESTRICT=nodistcc support
some notes: - setting CC=distcc is wrong, dont do it - RESTRICT values arent supposed to be prefixed with 'no' - the error looks like maybe your distcc hosts have a mismatch in linux-headers ? Thanks for the comment regarding "CC=distcc" -- I'll take note of that. Regarding different linux-headers: in fact, the other machine in my distcc pair was not powered up, so: there is no possibility of linux-headers issues, although I will also take note of this, since the other machine runs 2.6.x I'm getting a similar error while trying an emerge --update. The output looks like this:
.....
>>> Source unpacked.
_tkinter
./configure --prefix=/usr --host=i586-pc-linux-gnu --mandir=/usr/share/man --inf
odir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var
/lib --with-fpectl --enable-shared --disable-ipv6 --infodir=${prefix}/share/info
--mandir=${prefix}/share/man --with-threads --with-cxx=no --enable-unicode=ucs4
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking MACHDEP... linux2
checking EXTRAPLATDIR...
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for i586-pc-linux-gnu-gcc... i586-pc-linux-gnu-gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... configure: error: cannot compute suffix o
f object files: cannot compile
See `config.log' for more details.
!!! Please attach the config.log to your bug report:
!!! /var/tmp/portage/python-2.3.4-r1/work/Python-2.3.4/config.log
!!! ERROR: dev-lang/python-2.3.4-r1 failed.
!!! Function econf, Line 485, Exitcode 0
!!! econf failed
!!! If you need support, post the topmost build error, NOT this status message.
The /var/log/distccd of the distccd server yields:
distccd[25638] (dcc_execvp) ERROR: failed to exec i586-pc-linux-gnu-gcc: No such file or directory
This error seems to be related to the fact that my distcc client machine (old pentium notebook) has gcc linked (logically) to i586-pc-linux-gnu-gcc while the distccd server (Pentium4) has it linked to i686-pc-linux-gnu-gcc.
Could you check your /var/log/distccd on the distccd server?
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) Consider this closed as CANTFIX. While distcc usage could be disabled this way it's hard to adjust MAKEOPTS accordingly (and -j10 or so on a uni-core box is a bit insane). Also distcc problems are generally parallel make problems so this would just hide the problem, not solve it. |
