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?
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.
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.
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.
6 vs. 16 seconds? Sounds great for a full instruction set emulation/translation of dense numeric code. :)
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.
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 ;-)
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.
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.
Corey: hey, that is indeed a nice thing. Personally I’ll prefer a proper install though, so I have a true backup system around.
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.
Try this:
env CFLAGS=-m32 ./configure
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.