This is another one of these bugs related to builds not honoring the CC environment variable. The build system in cdrtools sets the compiler to "gcc" which breaks distcc compilation across different architectures. Reproducible: Sometimes Steps to Reproduce: To reproduce one needs to have such a setup. In my case this was a Pentium II Gentoo host, using distcc with a PowerMac G3 running Gentoo/PPC and an Athlon running Windows 98 SE. Results will varie depending on race conditions (what gets compiled where), but will almost always result in failed build (incompatible .o files). Actual Results: When linking ld burped with an error message saying it was facing a non-ELF .o file. Expected Results: Thankfully cdrtools' build system does use a CC variable inside its Makefiles, so adding CC=${CC} to emake's arguments fixes the issue and the build succeeds. fguimond@salamander fguimond $ emerge info Portage 2.0.49-r21 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9, 2.4.22-gentoo-r5) ================================================================= System uname: 2.4.22-gentoo-r5 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.3.10 distcc 2.11.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=pentium2 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-mcpu=pentium2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distcc sandbox" GENTOO_MIRRORS="ftp://gentoo.noved.org/ http://gentoo.noved.org/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X alsa apm arts artswrappersuid avi berkdb cdr cjk crypt cscope cups dga doc encode esd faad foomaticdb gatos gdbm gif gnome gpm gtk gtk2 imlib java jpeg justify kde kerberos lcms ldap libg++ libwww mad mbox mikmod mmx motif mozilla moznoirc mozsvg mpeg nas ncurses nls objc oggvorbis opengl oss pam parse-clocks pdflib perl pic png ppds python qt quicktime radeon readline ruby samba sdk sdl slang slp spell ssl svga tcltk tcpd tetex tiff truetype vim-with-x wmf x86 xml xml2 xmms xv zlib"
Created attachment 24466 [details, diff] patch fixing it on current stable ebuild
I'll test it. I will start the emerge on my G3 and use my PIII for distcc. It's the other way round you used it, but that should not matter.
I could not reproduce the errors in my crossdev-environment. But as the addition to emake does not harm the compilation process, I added it to the ebuilds (alpha23 and alpha25). Thanks for reporting and I'll close this bug.
I think that's the reason a lot of these bugs still roam around, because they depend on many build-time factors that can hide them. I -know- there are a lot more out there which are using get_number_of_jobs (or make directly without -j parameters) because that will make it compile locally in nearly all cases. Fact is, distcc is still enabled even in these cases, so if you start another compilation in parallel using the same DISTCC_DIR, even the above ebuilds still start spreading jobs to distcc hosts and might expose new bugs. distcc and ccache are nice tools, but in some situations they get dangerous.
