Planning to Compile My Own QEMU Binaries
by Mike Levin SEO & Datamaster, 05/22/2012
Note: Since I wrote this article, I’ve released my own Linux distro remix called Levinux, which runs with a double-click from a Mac, Windows or other Linux desktop. I gave up on compiling my own binaries for awhile. The latest QEMUs are to dependency-laden to get it to work perfectly the way I need across all 3 platforms.
I really need to structure this website around my mission. Right now, it’s eight years of articles from all over the place. Step one has been consolidating all my sites onto MikeLev.in, getting comfortable with WordPress, and forcing myself to use it as my daily work journal. Step one is done.
Now I have to make this site purposeful. I need to relentlessly work every day towards my goal, and make the organization and content of this site reflect that. It’s clear that there are daily trials and tribulations that I will document for their stand-alone value, like yesterday’s diversion into clusterssh for Rackspace cloud synchronization. These are the best sorts of diversions, because they fit cleanly into the big picture.
But more often, I need to push forward on fronts that I have been remiss to do so far. Namely, finish version 1.0 of Levinux, which I can see now will be hosted at MikeLev.in/ux! This has triple and quadruple entendres going. But the problem I’ve had so far was not being happy with the QEMU cocktail I had going in order to boot (dependency-free) on Mac, Windows or Linux desktops.
Namely, I was unhappy with the Mac mishmash app bundle that the ancient Mac-friendly “Q” version of QEMU puts together as a stand-alone VM, and my inability to get a dependency-free version on Linux that doesn’t require the KVM common libraries to be pre-installed. My solution is to compile a statically-linked version of QEMU on each platform. That will add some sanity to the QEMU cocktail recipe.
Ideally, I have a single QEMU binary for each platform, which compiles all it’s dependencies directly into the binary (statically linked). I will of course need a separate bios file possibly for each platform, but the virtual drives and initfs will be shared. Maybe I drop everything into the same folder, if I can avoid naming collisions, make that folder an OS X app package with the .app extension, but then put the Linux and Windows launcher scripts beside that folder.
Inside the folder ideally is a QEMU binary executable for each platform, as few bios files as necessary, the externalized kernel image for easy updating (thanks to QEMU allowing it), the involatile raminitfs file that Tiny Core Linux uses as the main system for an incorruptible RAM-resident main system, and a few additional qcow2 virtual drives for installed apps and stuff.
In such a scenario, path-issues are eliminated because everything looks for what it needs where it’s located. File cruft is at a minimum because I don’t start with these bloated QEMU supports-everything pre-compiled distributions. And I start to get the hands-on I need with QEMU configuration at the compile step, turning off what I don’t need.