A classic problem for development of a Linux distribution that supports multiple variants of the same architecture is determining exactly how the two similar but directly incompatible architectures should coexist on the same system. By far the most obvious and well-known example of this is running 32-bit i386/i686 software on a 64-bit x86-64/amd64 Linux system. On these so-called “multilib” systems, the typical solution is to segregate 32-bit libraries into a separate folder such as /lib32 or /usr/lib32, and placing 64-bit libraries in /lib64, /lib, /usr/lib64, or /usr/lib, depending on the implementation. Oddly enough, there is almost never a /usr/bin64 or similar matching separation for programs themselves. This is very troublesome in that there is no fully standardized way to combine everything. Additionally, if you generate a large set of packages for an i686 system, those packages cannot be re-used on the x86-64 system without one of two things happening:

• The 32-bit software being recompiled to use special paths, or
• The 64-bit software being compiled with special paths to “work around” the 32-bit ones.

Compiling packages with “special” path names and patches poses a significant problem in itself: every software package builds in a different way, and often assumptions are made about the location of libraries, binaries, and so forth that aren’t compatible with multilib directory layouts. The burden on software developers increases, and maintainers must ensure that their maintained software packages are compatible with their distinct “flavor” of multilib implementation (and patch them if they are not).

AlterEgo provides a third option. Imagine if 32-bit and 64-bit packages could simply be configured as “pure” systems, where library and binary directories only contain software of the correct variant, and no concessions for multilib support are required. This has always been easily done through the use of the “chroot” command, by unpacking the entire incompatible variant into a directory and then changing root into that directory, under which all of the required libraries and files are placed exactly as needed. However, one very important piece of the puzzle has been missing: using chroot requires root access, and integrating 32-bit programs into a 64-bit host system is not nearly as simple as making a symbolic link because chroot is required first. AlterEgo fills in that gap.

With AlterEgo installed, a program in a hard-coded chroot directory can be executed from the incompatible host system exactly the same as if it were installed normally. The trick is to route the program through AlterEgo via a symbolic link. For example, torun 32-bit Firefox on a 64-bit host, with the 32-bit host files unpacked and living in /i386:

ln -s /usr/bin/alterego /usr/bin/firefox
/usr/bin/firefox
(AlterEgo chroots to /i386 and runs /usr/bin/firefox automatically)

Note that while AlterEgo solves the chroot problem, you will still have to bind-mount any folders you wish to share with in the 32-bit system; the classic examples being /home, /var, and /etc; in the system startup scripts, it’s an excellent idea to set these mounts up automatically:

mount --bind /home /i386/home
mount --bind /etc /i386/etc
mount --bind /var /i386/var