I just began working seriously on installing desktop machines in 64 bits at work, and this gave me some insight into the 64 bits transition problems: biggest being commercial applications that work only in 32 bits.

I am going to describe here the Adobe applications to read PDF files (crobat Reader) and Flash files (flash plugin). However, the setup has to be a bit more specific. These applications work quite well in 32 bits, and the traditional piece of advice is to install a chroot in 32 bits, i.e. a mini-replica of a complete system in 32 bits. If you choose this method, lots of HOW-TOs do exist elsewhere. I did not want to do that for its many defaults. So I decided to install these applications as biarch applications, i.e. with 32 bits system libraries sitting next to the 64 bits ones. The processor then uses a special mode that accepts 32 bits instructions as well as 64 bits instructions.

Choice of the model: chroot or biarch?

The first choice was to eliminate the chroot method for its multiple defects:

1. A 32 bits chroot needs to be updated like a real system. Fine for a personal desktop machine, not for a whole bunch.
2. It is pretendingly easier to become root when allowed the access to a chroot. This is only a small problem, since we use NFS anyway.
3. Applications and bindings have to be duplicated. For example, the /tmp directory is specific to the system or chroot, and this is quite disturbing (esp. since some programs such as cups-pdf are configured here to drop their results in /tmp). And this spoils some good disk space.
4. All the programs launched in 32 bit userspace need appropriate wrappers, and this must be chosen at the program launch.

There are others, probably, but I was already convinced.

Acroread or work already done

There are some questions about wether installing acroread is not pointless: why in a world with xpdf or evince should one use Acrobat Reader? Because some artifacts remain, and I am in no position to decide that some files are non-printable even tough they were before. For example, the world maps that I produced for a wargame I participate in is open so slowly (on modern good desktop machines) by xpdf due to the fact that it cannot make partial rendering (something that Acrobat does effortlessly).

I know rather well the acroread package, my name being already in the changelog. The work is already done in fact (see the Debian FAQ Debian for AMD64). I just had to take the package available in the debian-multimedia repository (acroread_7.0.9-0.2sarge1_i386.deb). Once done, I just made the following modifications:

• Extract the contents of the package: dpkg -x acroread_7.0.9-0.2sarge1_i386.deb /tmp/acro
• Extract the metadata of the pacakge: dpkg -e acroread_7.0.9-0.2sarge1_i386.deb /tmp/acro/DEBIAN
• Change the metadata of /tmp/acro/DEBIAN/control: add a dependency on ia32-libs-gtk and ia32-libs. Change architecture from i386 to amd64.
• Modify /tmp/acro/usr/bin/acroread so that the last lines become:

export GTK_PATH=/usr/lib32/gtk-2.0/
export GCONV_PATH=/usr/lib32/gconv
export PANGO_RC_FILE=/etc/pango32/pangorc
export GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders.32
export GTK_IM_MODULE_FILE=/etc/gtk-2.0/gdk.immodules.32
exec "$ACRO_EXEC_CMD" ${1+"$@"}

• Repackage the whole thing: cd /tmp/acro;dpkg-deb --build; cd ..; mv acro.deb acroread_7.0.9-0.2sarge1_amd64.deb
• Do the same for acroread-escript (only the architecture to change) and acroread-plugins (the .../usr/lib/Adobe/Acrobat7.0/Reader/intellinux/plug_ins/PPKLite.api file must be deleted because incompatible with a 64 bits environment).

One gets three packages, perfectly working an installable on amd64. They are on my personal partial mirror. The list is here, but the packages may disappear if in the future there is an upgrade (they will be purged of the mirror):

• acroread
• acroread-escript
• acroread-plugins

Flash plugin (Adobe version)

It's a bit the same problem than for acrobat-reader: there is an alternative that can even read embedded video in Flash. But the compatibility is not perfect (and the developer himself says there is still much work to do), so I prefer to be on the safe side.

The work is also mostly done: the flashplugin-nonfree package works on both architectures (using nspluginwrapper package on amd64, that enables a 32 bits plugin in a Mozilla browser — Firefox, Iceweasel, etc. — in a transparent way). The detail is that the package was not yet compiled in the same version in both architectures, and I did prefer to have matching versions. This is now an obsolete detail, since the building software is now finished with it. So, done with it, one can see the scintillating images of YouTube twinkle in a 64 bits browser.

LibFlashSupport (support of sound by the Flash plugin)

There remained only one last detail, albeit an important one. The Flash plugin was mute! And I knew why. I use a sound server (PulseAudio) that does the multiplexing of the many sound streams. I think it can be done directly by ALSA (but there are conditions from what I read, see the red warning here). I never fully understood how to do that, and it remains much too esoteric for me. It does not work out of the box, too. Moreover, a sound server has over advantages like (graphical) management of sound level for each stream, network capabilities, etc. Well, I used that, and this was a requisite.

Even without the sound server, the Flash plugin does not behave well with other sound sources. It locks the soundcard for itself, and if it can't, it does not play any sound. If another program acted the same (the music player, even if paused), there is a problem.

The 32 bits answer to this is to use libflashsupport provided by Révolution Linux, a Canadian Linux company. This is completely free, and works OK. CJ van den Berg did build some Debian packages that contain everything necessary in 32 bits (even if a bit old). After one try, I did adopt this solution.

The 64 bits transition remained. I have the result, but it is not for the faint of heart. libflashsupport is in fact dlopen'ed by the Flash plugin if found (the try is always there, libflashsupport installed or not). The thing looks well conceived enough, since it is open in the 32 bits libraries collections. Recompiling the source was not that difficult, but it has to be done in 32 bits mode. The whole thing is done in a i386 chroot, and after several trials, it still does not work. Mffff, thank you, nothing to see, keep ahead. So I looked at the code. libflashsupport dlopens /usr/lib/libpulse-simple.so to see if the Flash plugin must use prioritarily PulseAudio (the esd, then oss) instead of ALSA directly. The dlopening cannot work, since /usr/lib/libpulse-simple.so is a 64 bits library.

So, I changed the code. libflashsupport now dlopens /usr/lib32/libpulse-simple.so (remark the difference). Everybody is happy this way. But libpulse-simple.so is obviously not in the few basic 32 bits libraries contained in ia32-libs and ia32-libs-gtk.

So, the last step. Where are those libraries. The simplest way was to copy them directly from the i386 chroot. I had to copy that library and all the necessary dependencies (libpulse.so, libssl.so, libcrypt.so, libcap.so). Everything goes in the source, and well, there will be no source package.

The result is a small working package, that is attached to this post.