Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

32-bit Shuffling

December 19th, 2008 by Multimedia Mike

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?

Posted in FATE Server | 12 Comments »

12 Responses

  1. dconrad Says:

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

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

    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:

    #!/bin/sh
    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. jpc Says:

    6 vs. 16 seconds? Sounds great for a full instruction set emulation/translation of dense numeric code. :)

  5. Multimedia Mike Says:

    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.

  6. Reimar Says:

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

  7. Reimar Says:

    Oh, I forgot: you can also create a few-GB file and the replace
    /dev/sda2 /debian ext2 exec,noatime 0 0
    by
    /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.

  8. Corey Says:

    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.

  9. Reimar Says:

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

  10. Multimedia Mike Says:

    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.

  11. D. Adam Karim Says:

    Try this:

    env CFLAGS=-m32 ./configure

  12. Chris Says:

    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.