Re: Aw: [gentoo-user] Re: Some essential packages fail to compile

[Andrea Conti]

> 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