32-bit Shuffling

I decided to put that cross compiling effort on hold. I can’t get any cross compilers compiled and even if I could, if seems like a silly effort without any special hardware to test, or until I budget time to figure out how qemu works. (Though I am still pondering a MIPS-based laptop; if anyone knows where to find a Alpha-400 or Razorbook or any of the other dozen names it’s marketed under, for cheaper than Geek’s.com sells them, let me know.)

However, I am always reorganizing, always shuffling things around. When I got a Mac Mini in the first month of this year, I only meant for it to run x86_64 FATE cycles in a VMware Fusion session, and maybe native Mac OS X cycles. Now, the little box serves as my primary home desktop; I have fully migrated off of my old Windows XP desktop. So every time there was new code in FFmpeg SVN, the Mac Mini would run FATE cycles for x86_32/Linux, x86_64/Linux, and Mac OS X, all in parallel — and there are only 2 CPU cores and 3 GB of memory in play here. Things could slow down during primetime.

After I migrated to the Mac Mini as my primary desktop, I completely decommissioned and stowed the old WinXP box (which has a little more overall processing power than the Mac Mini). It didn’t take long before I realized that I should slap 64-bit Linux on the thing and put it back into service as a dedicated FATE box.

I quickly migrated all the x86_64 configurations over to the new box, thus easing the load on the Mac Mini. However, I think it would be useful to migrate the x86_32 configurations over as well. x86_64 is alleged to be able to run x86_32 binaries as well, just as long as any dependent 32-bit libraries are installed.

So the goal is to get this x86_64 Linux box building 32-bit binaries. Things I have tried in order to achieve this end:

  • I installed the libc6-dev-i386 package on this Ubuntu-based machine; I understand that’s crucial to running basic 32-bit binaries.
  • As a baseline, I tried getting the native gcc compiler (4.3.2) to build a 32-bit binary.
  • I have a bunch of compilers already installed on the 64-bit machine that I copied wholesale from the old x86_64 VMware session. I tried to convince them to compile 32-bit binaries.
  • I also have a bunch of gcc versions sitting on the x86_32 VMware session. Armed with the knowledge the x86_64 machines allegedly run x86_32 binaries, I copied the directories whole to the new machine.

The short story is that nothing worked. At the very least, I figured out that x86_32 is not a suitable arch to specify to FFmpeg’s configure script; these are the suitable x86_32 strings: “i386|i486|i586|i686|i86pc|BePC”. But that only goes so far toward solving the problem. Running the 32-bit compiled compilers makes ld segfault during FFmpeg’s detection. The transplanted 64-bit compilers failed during the configuration due to a failure to locate a suitable libgcc.a. I likely explicitly disabled multilib (–disable-multilib) when building them because… probably because it’s the only way they would compile. I’m pretty sure that multilib in this context pertains to building a 64-bit compiler that can spit out both 32- and 64-bit binaries. But I can never get 64-bit gcc to build with multilib. And if you google for the error message in question — something about not finding gnu/stubs-32.h — you will just find pages upon pages of forum posts from people who are trying to compile gcc on 64-bit platforms and who eventually arrive at the solution to — you guessed it — configure with –disable-multilib. After all, who really needs to wants to compile 32-bit binaries on a 64-bit machine?

The native compiler solution got the farthest, but that bombed out on an inline assembly error related to H.264. This was another concern I had about the whole process: is the Makefile set up to compile raw ASM files correctly via YASM? (I know that YASM != inline ASM, but the 2 topics are tangentially related.)

Sometime back in the early days of FATE, someone asked why I didn’t run the 32- and 64-bit FATE configurations from the same 64-bit machine. Is this a good enough answer?

12 thoughts on “32-bit Shuffling

  1. dconrad

    Of course, this also explains why the number 1 comment on your other blog was “64-bit flash zomg!” Linux distros do not seem to care about making 32-bit apps easy to run in a 64-bit OS.

    On a side note, if you want to stress out that Mac mini even more, you can cross compile for OS X/PPC with ./configure –enable-cross-compile –arch=ppc –extra-cflags=”-arch ppc” –extra-ldflags=”-arch ppc” It’ll run slowly, but with absolutely no hassle.

  2. Multimedia Mike Post author

    Hey, neat trick:

    $ file ffmpeg
    ffmpeg: Mach-O executable ppc

    and it even executes. Maybe that’s what Diego meant when he advised building and testing Mac/PPC.

    You weren’t kidding about the speed. I tried one of the most arduously slow FATE tests— it takes about 16 seconds for that test to run, vs. 6 seconds for the native 64-bit build. Still, it might be interesting to add this configuration if I can migrate the Linux/x86_32 configurations away from the Mac Mini.

  3. Reimar

    Your issues are the reason why I gave up on multilib.
    My setup? I unstalled 32 bit debian in another partition, added these to /etc/fstab:

    /dev/sda2 /debian ext2 exec,noatime 0 0
    /tmp /debian/tmp none bind 0 0
    /sys /debian/sys none bind 0 0
    /dev/pts /debian/dev/pts none bind 0 0
    /dev/shm /debian/dev/shm none bind 0 0

    (note that bind-mounting /tmp is necessary to make X work flawlessly for 32 bit apps, some apps also need
    /debian/proc to be mounted, but they are so rare and
    mounting /proc twice does (did?) not work right…)

    I then start a 32 bit session with this script:

    cp $HOME/.Xauthority /debian/$HOME/
    /usr/bin/linux32 /usr/bin/dchroot $@

    with /etc/dchroot.conf:
    deb /debian

    works fine for wine, google-earth and several binary-only games.
    Yes it is a bit of an effort once, but far less in the long term – it also means you have a (mostly) ready-to-run backup system if you ever break the first one.

  4. Multimedia Mike Post author

    Thanks for the chroot idea, Reimar. I had forgotten about that. This machine has a 400 GB drive Unfortunately, it’s already happily partitioned. Maybe I will research putting a 32-bit partition on a decent size USB drive.

  5. Reimar

    Can’t you resize some of the partitions? Never tried that with Linux partitions, I only know it works fairly well with FAT and NTFS ;-)

  6. Reimar

    Oh, I forgot: you can also create a few-GB file and the replace
    /dev/sda2 /debian ext2 exec,noatime 0 0
    /my/file /debian ext2 exec,noatime,loop 0 0
    Just make sure that the partition that contains the file is mounted first.
    Performance could be a bit ugly, but should still be better than USB.

  7. Corey

    For a minimal Debian installation, I like debootstrap, which appears to exist for Ubuntu as well. In a test run just now, it took me 10 minutes to set up an i386 chroot:

    # mkdir /tmp/test
    # cd /tmp/test
    # debootstrap –arch=i386 –variant=minbase sid . http://ftp.us.debian.org/debian/
    # echo “deb http://ftp.us.debian.org/debian sid main contrib non-free” > etc/apt/sources.list

    After that you may want to mount some filesystems into the chroot like Reimar said, and then:

    # chroot .
    # apt-get update
    # apt-get install

    The nice part is that you don’t end up with a kernel, boot loader, or many other packages that would be superfluous in a dedicated chroot (there are some unneeded packages, but not many), and the base installation size is relatively small.
    # du -sh .
    125M .

    Unless you have a particular need or desire to keep the chroot in a separate partition, there’s nothing wrong with simply having it in a directory of another filesystem. You can, of course, mount another filesystem into the chroot somewhere if you want to keep the build area separate.

  8. Reimar

    Corey: hey, that is indeed a nice thing. Personally I’ll prefer a proper install though, so I have a true backup system around.

  9. Multimedia Mike Post author

    Thanks for the Debian tips, all. Of course, I’m using Ubuntu, and I’d rather not get into problems with hosting one through the other. Fortunately, I found a page describing how to set up Debootstrap in Ubuntu. Unfortunately, it didn’t work right, at least not the first time. Fortunately, it is — as Corey noted — reasonably fast to start over again after scrapping the chroot, and I think this approach just might work.

  10. Chris

    Hi I was trying to compile an app 32bit as 64bit kept generating errors, and the -m32 does the job, sweet flags thanks D. Adam Karim.

Comments are closed.