> > 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