Tag Archives: gcc

About That 32-bit Chroot

Pursuant to my earlier frustration with building and running 32-bit binaries on a 64-bit Linux installation, I have returned to the chroot suggestions set forth in the comments section for that post. I found the DebootstrapChroot HOWTO on the Ubuntu Wiki which seems to be a fairly authoritative solution. Except that it didn’t work right for the many times I was trying to set it up some weeks ago.

I finally got the 32-bit chroot to work tonight. Thus, I am working to migrate the 8 x86_32 configurations over from the VMware machine. All of the gcc versions work when transplanted directly (2.95.3, though, is only happy living in the same path where it originally resided). I am rebuilding a new version of gcc-svn for x86_32 (no reason to migrate an old version when I am constantly updating from gcc SVN anyway). I could probably migrate the Intel C compiler wholesale, but it would probably be better to take this opportunity to finally upgrade from .15 to .17 in the 10.1 series, at least until Carl Eugen Hoyos gives the all-clear to upgrade to the later series (last I heard, it can’t handle the FFmpeg source).

For my future reference, as well as for the benefit of other confused Ubuntu users, I am documenting how I managed to set up the 32-bit chroot environment. I started with the instructions at https://wiki.ubuntu.com/DebootstrapChroot and found them to be mostly accurate but in the wrong order in some places. Mostly, it had to do with the mount points and when to activate them. The original Wiki describes chrooting as root, performing a bunch of apt-get package maintenance (section: “Setting up your chroot with debootstrap”), and only sometime later (section: “Getting stuff (…) working automagically”) setting up special mount points. Then later on (section: “Setting up a dchroot (non-root) environment”), the document recommends replacing the earlier mount points with a new set. Following those instructions in that order always left me with a confused and corrupted chroot setup. I solved the problem by setting up the second set of mount points before performing the initial package maintenance (and never using the first set).

Also, I found it very useful and bandwidth-saving to make a backup copy (‘cp -a /var/chroot/intrepid /var/chroot/fresh.intrepid’) after the cursory debootstrap command. Just in case, you know, it doesn’t work out quite right the first, second, … tenth time, you won’t have to wipe the chroot directory and download all the packages again from scratch.

Cross Compiled FATE

I have been considering the idea of adding gcc cross compilers to FATE. At first, I just want to try compiling some binaries to make sure the builds stay working; testing may come later via qemu or physical hardware.

There was once a time when I was reasonably competent at setting up cross compiling toolchains, when I was developing software for the Sega Dreamcast on a hobby basis (SH-4 and ARM toolchains). But I seem to have lost the skill somewhere along the line. Fundamentally, it involves configuring GNU binutils with an alternate –target than the default, native platform. The trouble is that it’s difficult to figure out exactly what the target is named. I recently tried to set up a toolchain for MIPS, just in case I should come into possession of a laptop with such a CPU. I couldn’t figure out if I needed a mips-elf target, or a mips32-elf target, or perhaps a mips32-linux-elf target. Nothing I tried worked.

Maybe I just don’t have the right targets. What would be some good, useful, cross-compiled targets to be building continuously with FATE? I suspect that, at a minimum, all of the targets for which FFmpeg has SIMD optimizations: Alpha, ARM, Blackfin, PS2-MIPS, SH-4, and Sparc.