I was wondering, since I will get my iBook soon, whether it's possible to cross compile gentoo for another platform (like ppc on a x86)? I know it's possible to cross compile code, but how practical is it to compile the whole system?

Simply replace the target and host parameters for the build arch and target arch, and it should work a bit.

As a second reference, daork, posted to the gentoo-sparc mailing list a guide on generating a sparc64 cross-compiler in sparc userland (sparc64 denotes 64-Bit userland while "sparc" denotes 32-Bit userland).

daork wrote:

The steps below are how to make a sparc64 compiler on a non-sparc(64)
system.
"sparc64" can probably be substituted for "sparc" to compile binaries for a
32bit userland.
After doing these steps, check out http://distcc.samba.org/. (Distcc is in
portage, but is masked for sparc).
This will allow you to use your perhaps faster Intel hardware to speed up
compiles on your perhaps slower Sparc hardware.

1 - make a dir for your cross compiler to reside. export that dir as PREFIX
2 - make these dirs: build-gcc-bootstrap build-gcc-full build-glibc build-binutils
3 - unpack the sources and apply patches as per the ebuilds. At the same time it may be worthwhile getting the configure lines from the ebuilds
4 - in the build-binutils dir run <path to binutils src>/configure --target=sparc64-unknown-linux-gnu --prefix=$PREFIX <ebuild options>
5 - make and make install binutils
6 - find some kernel headers and get the linux and the asm sub dirs and put them in $PREFIX/sparc64-unknown-linux-gnu/include (use the source tree you compiled your sparc's kernel from to get these headers. note: asm is a symlink, get asm-sparc64 and symlink it or rename it)
7 - goto the build-gcc-bootstrap dir and run <path to gcc src>/configure --prefix=$PREFIX --target=sparc64-unknown-linux-gnu --with-newlib --without-headers --disable-shared --disable-threads --enable-languages=c --disable-multilib (_NOT_ THE OPTIONS IN THE EBUILD)
8 - make and make install this gcc.
9 - goto the build-glibc dir and run <path to glibc src>/configure --prefix=$PREFIX --host=sparc64-unknown-linux-gnu --build=<your-current-platform> <ebuild options> (the current platform bit is to tell glibc to use your new gcc)
10 - make and make install it
11 - goto the build-gcc-full dir and run <path to gcc src>/configure --prefix=$PREFIX --target=sparc64-unknown-linux-gnu --disable-multilib <ebuild options>
12 - make and make install it
13 - have fun!

Hopefully this will provide a wealth of information regarding cross-compilers. It's ALOT more complicated than one thinks, and quite aggrivating at times.

Of note, if you intend to cross-compile for MIPS based platforms, then do not forget the mips patches included in the binutils tarball, otherwise your binutils package will generate some pretty b0rked executables.

First step, build a cross compiler on the athlon. Your best bet is to use the script from
http://www.kegel.com/xgcc3/
but you'll need to modify it a bit. Change the vars to use the same version of gcc / glibc / binutils as your gentoo box, remove any references to patching, and make sure you've got the source tars for the above. You'll also need to change the prefix for the compiler from powerpc-linux- to powerpc-unknown-linux-gnu to match the gentoo compiler.

Now, once that's up and running, i'm using distcc [ http://distcc.samba.org/ ] - this means that you don't have to worry about getting libraries and headers and stuff installed on your x86 box - you only actually need the xgcc there. You also need to tell distcc to use the ppc compiler (which it won't do by default on the x86 box) - so normally you'd set your environment vars as such:

I've made sure that /opt/xgcc3/ppc750/bin contains the fully qualified compiler names (powerpc-unknown-linux-gnu-gcc etc) but not the short ones (gcc..) - so any calls to just gcc fall through to the athlon native compiler. So, the same distcc server works for the iBook and for my other (x86) machines. (Of course, I try and get the other machines to use i586-pc-linux-gnu-gcc where possible...)

Also, I've changed my setup on the iBook a bit since I posted this, due to improvements in portage. I now have

I just wonder about the --with-newlib. AFAIK newlib is not part of gcc and you didn't mention it before. Why is it needed? Should it be built beforehand or should one place a symlink to it into the gcc directory, so that it is built together with gcc?

I finally found the answer to my newlib question in one of the referenced documents. However, another question just came to my mind (because I've got problems xcompiling glibc for m68k).

Kumba wrote:

1 - make a dir for your cross compiler to reside. export that dir as PREFIX
2 - make these dirs: build-gcc-bootstrap build-gcc-full build-glibc build-binutils
3 - unpack the sources and apply patches as per the ebuilds. At the same time it may be worthwhile getting the configure lines from the ebuilds
4 - in the build-binutils dir run <path to binutils src>/configure --target=sparc64-unknown-linux-gnu --prefix=$PREFIX <ebuild options>
5 - make and make install binutils
6 - find some kernel headers and get the linux and the asm sub dirs and put them in $PREFIX/sparc64-unknown-linux-gnu/include (use the source tree you compiled your sparc's kernel from to get these headers. note: asm is a symlink, get asm-sparc64 and symlink it or rename it)
7 - goto the build-gcc-bootstrap dir and run <path to gcc src>/configure --prefix=$PREFIX --target=sparc64-unknown-linux-gnu --with-newlib --without-headers --disable-shared --disable-threads --enable-languages=c --disable-multilib (_NOT_ THE OPTIONS IN THE EBUILD)
8 - make and make install this gcc.
9 - goto the build-glibc dir and run <path to glibc src>/configure --prefix=$PREFIX --host=sparc64-unknown-linux-gnu --build=<your-current-platform> <ebuild options> (the current platform bit is to tell glibc to use your new gcc)
10 - make and make install it
11 - goto the build-gcc-full dir and run <path to gcc src>/configure --prefix=$PREFIX --target=sparc64-unknown-linux-gnu --disable-multilib <ebuild options>
12 - make and make install it
13 - have fun!

If I intend to use the cross compiler only by means of distcc, wouldn't it be enough to do steps 1-6, 11 and 12 (and 13, of course ), since distcc only sends preprocessed code to the remote machines, but does preprocessing and linking on localhost (the target). So the xcompiling machines don't need target libs 'n headers.

wouldn't it be enough to do steps 1-6, 11 and 12 (and 13, of course ),

Depends what you want to do - if you only do these steps, you only have the gcc bootstrap compiler - ie. just a questionable minimal gcc, and I'm pretty sure there won't be g++ or any funky stuff. Try it!

wouldn't it be enough to do steps 1-6, 11 and 12 (and 13, of course ),

Depends what you want to do - if you only do these steps, you only have the gcc bootstrap compiler - ie. just a questionable minimal gcc, and I'm pretty sure there won't be g++ or any funky stuff. Try it!

No, I leave out the bootstrap compiler. I just build the full compiler in steps 11 and 12. To actually try it out, I'm desperately waiting for the m68k stage 1

Sorry, misread. In that case, I severly doubt it'll compile - it needs the libs. You're welcome to prove me wrong, though

Why should it need the libs? Again, I'm just talking about the distcc scenario as described in this thread. distcc just sends preprocessed code to the remote machines. Everything else is done locally. It is explicitely stated in the distcc docs that because of this (target) libs and headers are not needed on the remotes.

Glibc fails to build because it is confused about what host it is building on. I wonder if crosscompile.eclass can come to the rescue? I know that glibc crossbuilds correctly on its own because I do that all the time.

From the outside (of emerge) you have CBUILD, CHOST, and CCHOST. According to crosscompile.eclass (which no ebuilds use, btw) these correspond to --build, --host, and --target.

The only ebuilds that examine CCHOST are gcc and gpc. There are two use cases here: building a cross compiler and cross building a compiler. In the former case you want --host to be your current machine. In the latter case you want --host to be the target machine. I am primarily concentrating on the latter case.

BTW, why isn't CCHOST called CTARGET?

Also, binutils does not require --target and doesn't look at CCHOST.

The issue with glibc is that it ignores CBUILD. That is easily fixed, as shown in bug 26633. This ebuild does it's own configure operation, whereas the default one (econf) does the right thing with CBUILD. There seem to be a lot of ebuilds that do this, and I suspect they should likewise be changed to use econf.

As an exercise in almost certain futility, I'm seeing how far I can get with installing Gentoo-PPC on one of our embedded ppc_860 processors. I currently have one booting off NFS with the Montavista Hardhat distribution. I untarred the Gentoo-PPC stage 2 tarball and attempted to 'chroot'. Got a few library dependency problems, which 'LD_LIBRARY_PATH=/ppc-gentoo/lib' fixed. The next message was:

# LD_LIBRARY_PATH=/ppc-gentoo/lib ./bash
./bash: /lib/ld.so.1: version `GLIBC_PRIVATE' not found (required by /ppc-gentoo/lib/libdl.so.2)
./bash: /lib/ld.so.1: version `GLIBC_PRIVATE' not found (required by /ppc-gentoo/lib/libc.so.6)

This was 'fixed' by symlinking /lib/ld.so.1 in my hardhat NFS to /gentoo/lib/ld.so.1. Unfortunately, everything I now run segmentation faults.

Is there any way I can work out why it's segfaulting? I'm assuming here (and it might be a fairly big assumption) that the Gentoo-PPC stage 2 tarball contains binaries that can run on the ppc_860. Anybody know for sure?

Perhaps I'd be better off installing from Stage 1? I already have a cross compiler and glibc-2.3.2 cross-compiled. I noticed a 'Stage 0' tarball on the FTP server - what's that for?

Edit: as you can see, I have no idea what I'm doing... but it's been fun thus far...

As an exercise in almost certain futility, I'm seeing how far I can get with installing Gentoo-PPC on one of our embedded ppc_860 processors. I currently have one booting off NFS with the Montavista Hardhat distribution. I untarred the Gentoo-PPC stage 2 tarball and attempted to 'chroot'. Got a few library dependency problems, which 'LD_LIBRARY_PATH=/ppc-gentoo/lib' fixed. The next message was:

# LD_LIBRARY_PATH=/ppc-gentoo/lib ./bash
./bash: /lib/ld.so.1: version `GLIBC_PRIVATE' not found (required by /ppc-gentoo/lib/libdl.so.2)
./bash: /lib/ld.so.1: version `GLIBC_PRIVATE' not found (required by /ppc-gentoo/lib/libc.so.6)

This was 'fixed' by symlinking /lib/ld.so.1 in my hardhat NFS to /gentoo/lib/ld.so.1. Unfortunately, everything I now run segmentation faults.

Is there any way I can work out why it's segfaulting? I'm assuming here (and it might be a fairly big assumption) that the Gentoo-PPC stage 2 tarball contains binaries that can run on the ppc_860. Anybody know for sure?

Perhaps I'd be better off installing from Stage 1? I already have a cross compiler and glibc-2.3.2 cross-compiled. I noticed a 'Stage 0' tarball on the FTP server - what's that for?

Edit: as you can see, I have no idea what I'm doing... but it's been fun thus far...

Unfortunately no - I ran out of time and never spent any more on getting it working. It was just a 'try it and see' exercise at the time. I might have another crack at it one day. Please post here if you get it sorted.

Unfortunately no - I ran out of time and never spent any more on getting it working. It was just a 'try it and see' exercise at the time. I might have another crack at it one day. Please post here if you get it sorted.