Author: Nathan Willis
The easiest thing to do is to install a 32-bit browser inside a “chroot jail” — a minimalistic 32-bit system, including just the browser and the support libraries it needs to run (in this case, including specifically the 32-bit plugins and codecs), isolated from the rest of the system in a directory sealed off via the chroot command. You can launch the 32-bit browser from the 64-bit environment and it will connect and browse the Web like normal, but it will not be able to access resources on your machine installed outside of the chroot jail.
For normal browsing and viewing embedded media, this setup works like a charm. You can install plugins and media codecs directly from within the browser, in most cases. You can even install the 32-bit version of your distro’s package management application and keep everything up-to-date at little to no extra effort.
On the down side, the more you use your browser, the more helper applications and auxiliary tools you will find yourself installing to the chroot jail. For instance, even though BitTorrent downloads are usually handled by an external app, we still find most of them through links on the Web. Thus, in order to click-and-launch your favorite BitTorrent client from your 32-bit browser, you will have to install a 32-bit version of that client inside the chroot jail. To many people, having to install multiple versions of the same app is a little irksome; it seems inelegant.
This solution also requires that you use a distro available in both 32-bit and 64-bit builds — not usually difficult to find, but important to note.
You can typically find step-by-step instructions for setting up such a jail at your distribution’s user forum, wiki, or mailing lists. To give a specific example, I have used 32-bit builds of Mozilla Firefox in 64-bit Ubuntu. The instructions for doing so are in this thread at ubuntuforums.org.
Visit the library
A wholly different approach is to install a browser compiled for the 32-bit instruction set and linked not to the usual (64-bit) system libraries such as /usr/lib, but to a set of 32-bit equivalents (such as /usr/lib32). The Filesystem Hierarchy Standard does not dictate what multiple binary libs must be named, so it could vary from distro to distro, but the rule of thumb on a 64-bit system is that /usr/lib points to the 64-bit libraries, and /usr/lib32 to the 32-bit.
Of course, this illustrates one of the key problems to this approach: it is very distro-specific. Not only must your distro provide both 32-bit and 64-bit versions, it must ship with multiple-shared-library support. The odds are that if it does so, you will have no trouble setting it up and installing it — but if it does not, setting it up manually could be a far bigger headache than using the chroot jail method.
In addition, you must get ahold of a Web browser compiled for this cross-library system; that is to say, a binary linked to /usr/lib32 or the equivalent. A vanilla 32-bit binary designed for use on a 32-bit distro will not work. If such a cross-library package is available for your distro, you are on easy street. If not, good luck to you, but compiling your own is beyond the scope of this article.
I don’t mean to sound discouraging; my informal survey indicates that so many 64-bit Linux users run into this issue daily that most of the major distros are prepared for it. To return to my previous example, 64-bit Ubuntu ships with a set of packages designed for 32-bit compatibility, and kind souls have regularly spent their own time keeping a 32-bit-compatible Firefox package up-to-date with the most recent official releases.
Wrap it up
A third, perhaps less familiar, option is to use some mechanism to load 32-bit plugins into the 64-bit browser native to your system. Feel free to point out more if they exist, but the only solution of this nature that I am aware of is nspluginwrapper, a personal project started and maintained by Mandriva’s Gwenolé Beauchesne. Beauchesne has not released the full source yet, but intends to do so once he is pleased with its readability.
The package consists of a 64-bit “proxy” plugin that loads standard 32-bit plugins into 64-bit Mozilla-based browsers, and a small suite of configuration tools. Beauchesne lists the major commercial plugins (Acrobat, RealPlayer, and Flash) as compatible, but in theory any plugin that conforms to the Netscape Plugin Application Program Interface should work.
The instructions on Beauchesne’s page appear to be a little outdated, though, making reference to a command-line tool named nspluginwrapper that was not installed with the bundle I downloaded. Luckily, instructions from helpful users in this ubuntuforums.org thread cleared up the confusion — the command line tool is named npconfig.
Do without
And we must not overlook the final option: sticking with a 64-bit browser and making do — one way or another — without the missing plugins and codecs. This can mean any number of specific behaviors: refusing to look at certain content, waiting patiently until 64-bit plugins become available, lobbying plugin and codec makers, or putting your faith in free alternative viewers such as Gnash.
Clearly a working free plugin is superior to a non-working non-free plugin; it is the grey areas in between that determine which tactic you prefer.
It would be nice to have the luxury to say, “if I can’t view this content the way I want to view it, I’ll just do without it.” But for most of us, dealing with closed-source browser plugins and multimedia codecs are a necessity. Those of use on the AMD64 architecture are the lucky ones: we can pull a few strings and use i386 plugins without too much trouble. We even have more than one option.
Right now, the chroot method is the easiest to set up and configure. Alternatively, the /lib32 method uses less disk space and eliminates the need to maintain multiple binaries of certain programs. But the wrapper-plugin method exemplified by nspluginwrapper is the most conceptually elegant. It’s less stable, but if it takes off, the approach could potentially work wonders not just for AMD64 users, but for any users who browse the Web on different architectures.
