> One way is (if you have read any 'environment' files in my tar archive) to > set the guest architecture explitcitly in /etc/(portage/)make.conf which I > did. > > /etc/make.conf: > CFLAGS="-O2 -march=i686 -pipe -fPIC -m32" > CXXFLAGS="${CFLAGS}" > CHOST="i486-pc-linux-gnu"
That is not "setting the guest architecture explicitly", you're just telling whatever compiler gets invoked on the remote host to produce 32-bit output. Cross-compiling with distcc is quite straightforward. As long as distcc is setup correctly on the client (which for cross-compiling involves a manual step, see below), and as long as the ebuilds properly invoke the compiler with the CHOST prefix (i.e. 'i486-pc-linux-gnu-gcc' instead of 'gcc'), the appropriate compiler will be called on the servers, with no need to manually play with your CFLAGS. If you need -m32, it means you are *not* cross-compiling, i.e. you are invoking the native gcc on the remote hosts instead of your cross-compiler. That usually works as any x86_84 gcc with multilib support can produce 32-bit output, but it is just masking the problem and will break if the -m32 flag is lost for some reason. > I left the default CHOST as is and on the Debian systems I provided the > required compiler. "provided the required compiler" should mean that on every server you have a complete 32-bit toolchain (binutils, gcc, glibc and kernel headers) with the version of each component matching those on your distcc client. You should be able to compile a 32-bit executable locally on any of the Debian systems just by invoking 'i486-pc-linux-gnu-gcc'. Setting up such a toolchain can be quite a PITA, so on Gentoo it's usually done with crossdev -- but as long as you get things right that's not a requirement. > One of the nodes has compiled a 64 bit object (conf.o) which the linker > (running on 32 bit) tried to link to a 32 bit program/library (the output). > So for me, the Makefile in that package (klibc) didn't provide the specified > CFLAGS I configured which needs fixing, if my assuming is right. I can deeper > more investigate here. > export HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > I think this line only needs to be extended with $(CFLAGS) then the fix is > complete. No. CFLAGS are for the build target, HOSTCFLAGS are for the build host. Building (configuring, actually) klibc involves compiling a tool which is run on the host (i.e. the machine you're building on), before compiling klibc itself for the build target. In your case both the host and the target are the same (i486-pc-linux-gnu), so the difference might not be very clear, but if you were compiling klibc for a different arch (e.g. powerpc) you would have a completely different build target, with its set of CFLAGS. Back to your problem, the klibc build is correctly picking up your HOSTCC: >>>> Source unpacked in /var/tmp/portage/dev-libs/klibc-1.5.20/work >>>> Compiling source in >>>> /var/tmp/portage/dev-libs/klibc-1.5.20/work/klibc-1.5.20 ... > make -j6 defconfig CC=i486-pc-linux-gnu-gcc HOSTCC=i486-pc-linux-gnu-gcc but distcc seems to be invoking the native x86_64 compiler (i.e. 'gcc') on the remote systems (you can also see all those warnings about differing integer and pointer sizes). My guess is that you didn't set up properly distcc for cross-compiling on your client. Try following the instructions at http://www.gentoo.org/doc/en/cross-compiling-distcc.xml and let us know if it fixes your problem. HTH, andrea