Advanced Micro Devices (AMD) developed a series of 64-bit extensions to their 32-bit RISC-based Intel IA-32 (i386) compatible processors. AMD sell their AMD64 (x86-64) architecture processors under a range of names: Athlon 64; Turion 64; Phenom; Opteron and Sempron (only the latest generation).
Initially Intel chose not to extend their IA-32 processor family to 64 bits, preferring to promote their own but incompatible HP PA-RISC based IA-64 "Itanium" processor family, later Intel adopted AMD's 64-bit extensions into their IA-32 processor family, calling them "Intel 64" (aka IA-32e and EMT64). Final generation Pentium 4 & D, Celeron D, and Xeon processors and all "Core 2" based processors now include AMD compatible 64-bit extensions.
Most currently available AMD and Intel processors are 64-bit enabled. Other x86 compatible processors such as Via Technologies' C3 & C7, SiS 552 and AMD Geode are not 64-bit capable. Intel's Itanium family while 64-bit are not directly compatible with Intel's x86 architecture.
AMD's AMD64 and Intel's Intel64 are able to run in two basic modes: long mode - a 64-bit clean mode where most clean 32-bit applications can still run; and legacy mode - where the processor runs as if it were an older 32-bit processor supporting various obsolete legacy modes and there is no access to 64-bit features.
An AMD64 processor started in 64-bit mode can run 64-bit and 32-bit applications at the same time but if started in 32-bit mode cannot run 64-bit applications until it has been restarted. It is therefore possible to start a system in 64-bit mode and run 32-bit applications side-by-side with native 64-bit applications but you cannot run 64-bit applications on a system started in 32-bit mode.
Debian GNU/Linux is available in two versions for AMD64 processors: i386 - is the traditional IA-32 version running in legacy mode; and AMD64 - is a new 64-bit version that takes full advantage of the new 64-bit features. In Debian 3.1 "Sarge" the AMD64 port was available and supported but declared "unofficial", in Debian 4.0 "Etch" it is a fully supported architecture. Within Debian, the i386 port has greater package coverage than the AMD64 port.
Although almost all packages are available compiled into native 64-bit AMD64 machine code, there is a handful of packages, in particular third party closed-source applications, that are not. These applications will not run directly in Debian AMD64. However, there are several methods to overcome this problem: dual boot/VM; a 32-bit chroot; and using the ia-32 suite.
One crude and inefficient method of running 32-bit applications on a 64-bit system is to dual boot the system, one i386 installation and one AMD64 installation side-by-side. This works but is hardly practical - rebooting just to run a 32-bit application that is not supported on a 64-bit system is cumbersome and disruptive.
A slightly better approach is to install and run a complete 32-bit system on in a virtual machine such as Qemu, VirtualBox, or VMWare. As with dual booting, this works but it is somewhat clunky and slow.
The AMD64 processor is able to quickly switch between 32-bit and 64-bit modes on the fly, thus small static 32-bit applications should work perfectly on a 64-bit system without any modification to either the system or the application. Alas, most modern applications dynamically link to one or more libraries and it is essential that applications link to libraries of their own type or the program will fail.
One easy way to obtain this is to install a 32-bit system, complete with all libraries and applications but without a kernel, into a chroot. A chroot is a software device that creates a "jail" on the host's file system and applications running inside the jail cannot see out off it.
Creating and running a 32-bit chroot is clearly explained in the Debian AMD64 How-to linked below. It is relatively easy to do but like the dual boot and virtual machine solutions it requires a lot of disk space and is a lot of effort if you only need one 32-bit application.
The Debian system dynamic library linker has been modified so that when a 32-bit application requests access to a library, Debian provides the 32-bit version of the library if it is available instead of the normal 64-bit version that the native applications require. This works if the ia32 packages which provide a sub-set of standard Debian libraries compiled in 32-bit mode have been installed.
To install the ia32-libs package use the command
sudo aptitude install ia32-libs. This creates a document tree in the
/emul/ia32-linux directory. By default this supports only console applications, basic X applications and GTK based applications. There are no 32-bit Qt or KDE libraries provided. If you want to run a Qt application, for example Opera, you should manually download, extract and install the 32-bit Qt libraries into this document tree, see apt-file code example below.
To find out what libraries are needed use the
ldd command - be aware that the file you think starts the application is often a script, and you may have to dig a bit to find the actual binary. The example below is for Real's RealPlayer application, which is only available as 32-bit closed-source binary.
$ ldd /usr/lib/realplay-10.0.8/realplay.bin linux-gate.so.1 => (0xffffe000) libgdk-x11-2.0.so.0 => /usr/lib32/libgdk-x11-2.0.so.0 (0xf7ed2000) libatk-1.0.so.0 => /usr/lib32/libatk-1.0.so.0 (0xf7eb8000) ... many deleted lines... libpangoft2-1.0.so.0 => /usr/lib32/libpangoft2-1.0.so.0 (0xf7678000) librt.so.1 => /lib32/librt.so.1 (0xf765d000) /lib/ld-linux.so.2 (0xf7f6a000) libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf75ea000)
Now all the required libraries have been found and RealPlayer should now be able to start without a problem.
If a library is missing use
apt-file to locate the missing package. In the example below the linker needed to link to
/usr/lib/compiz/libgconf-dump.so that was not installed.
# Install and update apt-file $ sudo aptitude install apt-file $ sudo apt-file update # Search for the package containing the required library $ apt-file --architecture i386 search libgconf-dump.so compiz-plugins: usr/lib/compiz/libgconf-dump.so compiz-plugins: usr/lib/compiz/libgconf-dump.so compiz-plugins: usr/lib/compiz/libgconf-dump.so compiz-plugins: usr/lib/compiz/libgconf-dump.so # Download the 32-bit library you require $ wget http://ftp.uk.debian.org/debian/pool/main/c/compiz/compiz-plugins_0.2.2-1_i386.deb # Extract it into your 32-bit library tree $ sudo dpkg -X compiz-plugins_0.2.2-1_i386.deb /emul/ia32-linux
Note that some GTK applications such as RealPlayer start correctly but there is a font problem - all the glyphs are boxes rather than letters. To solve this you have to manually provide 32-bit Pango settings (from the Xara LX web site):
# Create a 32 bit pixbuf loaders file: $ sed 's:/usr/lib/:/usr/lib32/:' < /etc/gtk-2.0/gdk-pixbuf.loaders >\ > /etc/gtk-2.0/gdk-pixbuf.loaders32 # Create /etc/pango32/pangorc with the following in: [Pango] ModuleFiles=/etc/pango32/pango.modules [PangoX] AliasFiles=/etc/pango/pangox.aliases # Insert the following environment variables into the environment that will # start the application, e.g. a start script or you .bashrc export GTK_PATH=/usr/lib32/gtk-2.0/ export PANGO_RC_FILE=/etc/pango32/pangorc export GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders32
This is all that is required to run most 32-bit applications from within a 64-bit Debian system.
There are several methods of running 32-bit applications on top of a 64-bit platform. Of the methods presented above the ia32 libs method is the most elegant and seamless - though it does require some effort to configure and maintain. Dual booting is the simplest but is highly disk space inefficient and not recommended. The chroot method is inefficient too and is as complex as the ia32 approach so I would not recommend it if the ia32 method works.