> > CFLAGS="-O2 -march=i686 -pipe -fPIC -m32"
> > CXXFLAGS="${CFLAGS}"
> > CHOST="i486-pc-linux-gnu"
I have reformated my disk because I missed a parameter (-d . or so) which would
make it possible for dracut to use gpg key decryption. Now I have to reinstall
all from scratch (including configuring kernel). In the meanwhile I figured out
that I choosed the wrong stage3 file (i486 instead of i686) (I have downloaded
http://de-mirror.org/gentoo/releases/x86/current-stage3/stage3-i686-20120710.tar.bz2
+ http://de-mirror.org/gentoo/snapshots/portage-latest.tar.bz2 now) which I
could fix now. So now CHOST="i686-pc-linux-gnu" is set.
> 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.
Guest from the other node's view. ;) Okay, to stop confusion:
Node name | Distri | Architecture
------------------------------------------------------------
daedalus | Debian Unstable | AMD64 (with multilib support)
router | Debian Unstable | AMD64 (same)
laptop | Gentoo | x86 (i686, reinstallation)
------------------------------------------------------------
One think I also need that 'daedalus' or 'router' can start 64 and 32 bit
compilations (e.g. wine should be better 32 bit, other games I play with are 64
bit compiled) which I would like to have. Most of these build systems sadly (!)
call gcc and g++ (both aliases), so I had to add -m32 for 32 bit apps/libs.
If I fully follow that wiki page (I did until the wrapper script is added) I
would have to change these links:
lrwxrwxrwx 1 root root 16 Sep 6 21:35 c++ -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 cc -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 g++ -> ../../bin/distcc
lrwxrwxrwx 1 root root 16 Sep 6 21:35 gcc -> ../../bin/distcc
... to the wrapper scripts which (I think so) will make it impossible to
compile 64 bits.
In my view my "fix" by adding explicitly the -m32 -march=xxxx flags may help
here better, as long as all packages are honoring them (which most do, except
those with x86_64 problems).
> 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.
Yes, i686-pc-linux-gnu-gcc and i686-pc-linux-gnu-g++ are just symbolic links to
the native compilers (because I don't have those binaries).
Here is a list:
------------------------------------------------------
daedalus:/usr/bin# ls -l i686-pc-linux-gnu-g*
lrwxrwxrwx 1 root root 7 Sep 8 18:55 i686-pc-linux-gnu-g++ -> g++-4.7
lrwxrwxrwx 1 root root 7 Sep 8 18:55 i686-pc-linux-gnu-gcc -> gcc-4.7
------------------------------------------------------
I have now the g++-multilib and gcc-multilib packages installed on 'daedalus'
and 'router', what now? They only contain libraries.
Should I better remove the symbolic links and add scripts there which adds -m32
-march=i686 to the parameter list (I could do it because those compiler names
are only used on 'laptop').
Roland
>
> > 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.
So CFLAGS and HOSTCFLAGS must be set to the same in make.conf? It is really
confusing. :(
> 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.
I used the lines from default gentoo installation and only added "-fPIC -m32".
> and let us know if it fixes your problem.
Okay.
Roland
