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

[Roland Häder]

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