I know, It’s a bit frustrating to own a 64bit machine and run 32bit binaries … so I’ve bootstrapped a 64bit CRUX-PPC system.
CRUX-PPC 64bit as the 32bit version will be (is) based on a multilib toolchain this make possible to compile 32bit binaries (and run 32bit binaries). CRUX-PPC 64bit share the 32bit version ones, although some of them need a little hack, generally the ones from the toolchain (in where it should be known on which and for which architecture it’s compiling); for example to the binutils configure we should pass the correct host type (of course the host type could be guessed, but what happen if you’re using a 32bit system on a 64bit platform?), so the binutils port have to be smart enough to set the correct host, this is done by checking the default cpu (32 or 64 bit one) for which the compiler compile and act accordingly; this is an excerpt from the binutils port:
SUBARCH="`gcc -v 2>&1 | grep with-cpu | sed 's|.*default||'`" if [ "$SUBARCH" == "32" ]; then SUBARCH="" fi AR=ar AS=as ../$name-$version/configure --prefix=/usr \ --enable-shared \ --enable-64-bit-bfd \ --host=powerpc${SUBARCH}-unknown-linux-gnu
Is this KISS anymore? Proabably yes, probably not. But only a little number of ports need this kind of hack so I think providing a full 64bit distribution that shares the ports with the 32bit one it’s a thing good enough to sacrifice a little of our KISSness.
gcc port has an hack like the binutils one where for setting the default cpu for which the compiler should generate the binaries. Automatically building the toolchain with a 32bit toolchain produces a 32bit toolchain and building it with a 64bit one produces a 64bit one … it’s a kind of “Strange Rings”.