Bugzilla Bug 39507

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 an attachment (id=24466) [edit]
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.