This site is now 100% read-only, and retired.

Using proprietary i386 apps on an amd64 system

Posted by dkg on Thu 14 Jun 2007 at 12:51

There's nothing like switching hardware architectures to make you realize one of the big advantages of free software: you can recompile all your free tools to use the new system. But what happens when you have a handful of non-free apps that were built for the old arch and you need to continue to be able to use them?

The Linux kernel for amd64 can actually run i386 binaries in a compatibility mode. But what if those apps depend on libraries that they expect to be provided by the system? The system libraries are now all built for amd64, so the i386 proprietary apps won't play nice with them.

Basic 32-bit library setup

For the i386 to amd64 transition, at least, you can install 32-bit libraries to be used by binaries which are running in the 32-bit compatibility mode. Debian is awesome: the really common libraries have already been packaged and organized for you, so you can just pull them in with:
apt-get install ia32-libs
If you're running a system with graphical tools (e.g. a desktop or a terminal server), you might also want to pull in the extra 32-bit GTK (GIMP ToolKit) libraries:
apt-get install ia32-libs-gtk

Filling in unusual missing libraries

Now most simple proprietary 32-bit binaries should run fine. But some more complicated ones want to rely on 32-bit libraries that haven't been nicely packaged by debian's amd64 team yet. How do you get and install those packages? There's good instructions in /usr/share/doc/ia32-libs/README.Debian:
If more libraries are needed, file wishlist severity bugs against ia32-libs
in the Debian bug tracking system at and we'll try to oblige.
For a quick fix, you can download a suitable ia32 (i386 in Debian architecture
terms) binary package, and install it on your ia64 or amd64 system using:

        dpkg -X .deb /emul/ia32-linux
You can use the trusty interface to find the right package and download a copy of the i386 version of the package from the mirror of your choice. Then, as root, use dpkg to extract the package as described in the snip above, and update the dynamic linker's run-time bindings with ldconfig.

It can be more complicated when you don't know what libraries are missing or needed. Sometimes, running the application will print out errors describing which libraries are needed. But you can also use /usr/bin/ldd to find out which libraries want to be dynamically linked at runtime (openssl in this example isn't a proprietary app, but i didn't have one handy; i pulled it in as an example app built for i386):

0 dkg@lemur:~$ uname -r
0 dkg@lemur:~$ file ./openssl 
./openssl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), for GNU/Linux 2.6.1, stripped
0 dkg@lemur:~$ ldd ./openssl =>  (0xffffe000) => not found => not found => /lib32/ (0xf7f2b000) => /usr/lib32/ (0xf7f16000) => /lib32/ (0xf7deb000)
        /lib/ (0xf7f38000)
0 dkg@lemur:~$ 

Finding libraries that aren't linked by ldd

If you've managed to install all the "not found" libraries from the i386 debian packages so that ldd isn't complaining, it's still possible that your proprietary binaries don't work. This is because some applications also use techniques like dlopen() to load shared libraries, instead of asking ldd to link them.

How can you figure out which libraries are needed if you don't have the source code? One way is to use strace. Do something like this as an unprivileged user:

DUMPDIR=$(mktemp -d)
strace -o $DUMPDIR/strace.out -f ./my-proprietary-app
now you can review $DUMPDIR/strace.out. Look toward the end of the file for attempts to open files with .so in their name (.so is short for shared object, which is a library):
grep open $DUMPDIR/strace.out | grep '\.so' | tail
You'll see a lot of lines like:
11829 open("/usr/lib/i486-linux-gnu/sse2/", O_RDONLY) = -1 ENOENT (No such file or directory)
11829 open("/usr/lib/i486-linux-gnu/cmov/", O_RDONLY) = -1 ENOENT (No such file or directory)
11829 open("/usr/lib/i486-linux-gnu/", O_RDONLY) = -1 ENOENT (No such file or directory)
Now you can look for a file of that name (ignore the path) in the debian i386 arch package web UI. For the example above, i would do a search for

Open questions

package tracking?
every package extracted into the /emul/ia32-linux doesn't get tracked by the package manager. What's a good way to get dpkg (or even better, apt!) to know about and maintain the package? How do we automate security updates, for example?
package verification?
Just downloading the package from the mirror doesn't tell us that we got what we were looking for. Since etch came out, we have the luxury of apt cryptographically verifying standard packages for us. What's a simple way to verify these packages before extracting them into /emul/ia32-linux?

Other methods

Another article on this site talks about how to install a full-blown 32-bit chroot instead of going with the emulated libraries. I don't think this is necessary for most cases, though i'd be curious to hear peoples' thoughts about the relative advantages or disadvantages of each approach. Certainly, if you plan to use non-free 32-bit libraries with your free applications, a chroot might be a better way to go. But if you've just got a couple non-free applications which want to use free 32-bit libraries, you might prefer the approach i've outlined here.



Re: Using proprietary i386 apps on an amd64 system
Posted by Anonymous (89.140.xx.xx) on Thu 14 Jun 2007 at 14:44
You could use apt-file to search which package contains a file (and not web interface)

Thank you

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by dkg (216.254.xx.xx) on Thu 14 Jun 2007 at 16:45
[ View Weblogs ]
Good idea! i'd never used this before, so i looked into it. As root, i did:
apt-get install apt-file
apt-file update
Now i can do requests as a regular user:
0 dkg@lemur:~$ apt-file --architecture i386 search
unixodbc: usr/lib/
unixodbc: usr/lib/
unixodbc: usr/lib/
unixodbc: usr/lib/
0 dkg@lemur:~$ 
If you suspect that you already have the package installed as a native 64-bit library, you could also use dpkg -S filename or dlocate filename to suss out the owning package.

One of the big advantages of the web interface is that it's a couple clicks away from a download of the package itself (and links to its dependencies). Do you know of a way to coax apt-file into downloading the package (and its dependencies?) from the command line? I think that would be ideal.

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by neofpo (200.185.xx.xx) on Fri 15 Jun 2007 at 04:28
[ View Weblogs ]
As reported previously by me, there is also the chroot solution. More work, but more generic.
I still wonder why does software industry still rejects AMD's 64bit plataform... There is also the excuse about old 32bit only code... but even 64bit hardware comes most times with 32bit operating systems.
I guess if it was Intel who had developed the 64bit arch, it would be market standard by now... Who knows...
Let us Debian geeks try to find ways to work arround it ;-)

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by dkg (216.254.xx.xx) on Fri 15 Jun 2007 at 06:41
[ View Weblogs ]
Yes, thanks for your article, neofpo! I was actually about to travel down the chroot route before i figured out the ia32-libs approach for a client. I figured i'd write up this approach before i forgot it ;)

I think one of the reasons that the proprietary software world hasn't picked up 64-bit computing as fast is that porting is hard, and there aren't many folks who do it well. In particular, it's a field of software engineering where it helps to have free and open communication between very different groups of specialists (specialists on the software being ported, specialists on the original architecture, and specialists on the target architecture). Since the free software world already does free and open communication quite well (and has tons of experience with porting), we've had a leg up on the proprietary world for this transition.

Intel actually did develop a 64-bit arch (the Itanium architecture, or ia64), but it was released earlier (when there was less need); it was more expensive; and i think it was not as backward-compatible as the amd64 chips (though i'm not sure on the details). It has been rejected/ignored even more egregiously than amd64 has been.

Of course, you can still run debian on ia64. ia32-libs appears to be built for it as well, but i've never tried it.

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by neofpo (200.185.xx.xx) on Fri 15 Jun 2007 at 14:36
[ View Weblogs ]
I know about Itanium, however, AMD's value was to keep one more time backward compatibility (where it was possible) with old code. AMD64 is almost a superset of ia32.

It is is nice to know that if one gives up all backward compatibility stuff on x86/amd64, the arch would gain about 20% speed / power efficiency directly. The Intel guy who said that pointed that nowadays speed is achieved by increasing speed / multicore tech rather than optimizing existing tech.

I guess if we had to put gas on computers, people would concern about efficiency. Electricity seems to just be there, we do not need to deal with nuclear garbage over our feet...

I believe NOW is the time to the software development industry see that open source / standards is THE only way to achieve better results cheaper. Even Microsoft is opening several projects on SourceForge.

Let me stop here, it is off topic enough the way it is.

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by yoush (81.195.xx.xx) on Mon 18 Jun 2007 at 20:35
For years, I've loved debian for quality of it's packaging system which always ensured system consistency.

The tricks described in this article are absolutely against Debian quality tradidion, and are a clear sign that amd64 port is fundamentally broken. When people ask me if they should install i386 or amd64 on their brand new amd64 hardware, I always answer - install i386 unless you want a system that has little in common with Debian quality traditions.

What is actually needed is a solution that allows to mix 32-bin and 64-bit binaries in the same filesystem, under complete control of package management tools. What multiarch people ( once tried to propose.

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by dkg (68.167.xx.xx) on Mon 18 Jun 2007 at 21:49
[ View Weblogs ]
I agree with you! Installing ia32-libs and ia32-libs-gtk work nicely within the "debian quality traditition", i think. But the remaining steps are clumsy, error-prone, and probably unmaintainable. That's why i included the "Open Questions" section in the article. Do you have any suggestions for tools we could use to make them more in line with the debian tradition?

I don't think that the debian tradition should force you into using old compatibility modes for your hardware if it's capable of better things and most of your tools are similarly capable. How can we fix this to better support tools that aren't ready to be fully ported to amd64?

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by Utumno (61.223.xx.xx) on Wed 20 Jun 2007 at 15:25
[ View Weblogs ]

I am running the chroot for 2 years now. I've got Firefox(for flashplugin) , Acrobat , GoogleEarth and Skype there.

The advantage of the chroot approach is that - at least I thought so - once you set it up, all i386 only stuff is guaranteed to work with no problems (?).

In practice, there are some problems. First, stuff like Acrobat has no access to files in the original AMD64 installation, unless you mount --bind it. But that has a hidden trap: I've got my /home mount --bind'ed. One day I decided to wipe out the chroot with a 'rm -rf' That wiped out the /home partition as well...

Besides, even with /home binded, how do I read PDF documentation from /usr/share/doc? Can't do it, mate...

More serious problem is with debugging. Once sound in Skype stopped working. Debugging this case proved much more challenging than if Skype had been native AMD64. Or details like, when you need to run a OSS-only i386-only sound app with a 'aoss' wrapper, how do you run it? 'aoss dchroot -c app' from AMD64 console, or maybe 'dchroot -c script' where 'script' is a i386 script in the chroot running 'aoss app' ?

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by Anonymous (98.224.xx.xx) on Sun 24 Aug 2008 at 17:22
Okay, so tell me this...

I've tried various methods of getting 32-bit libs on here. I've corrupted my machine slightly in that I've upgraded to Sid temporarily to get another package to install -- and failed miserably -- and since I didn't want to go through the hassle of downgrading everything all the way to ancien... I mean, "stable"... (upgrade of various programs required conf file changes or edits or something -- I don't quite recall, but I do remember the mail server being screwed up for weeks after), I simply downgraded just one step to Lenny/Testing. So now I have no doubt a few libs from all three subdistros.

That said, I can install ia32-libs (I should say, "install them again", because they WERE on here before) and its dependencies, but it WILL be a hassle since several programs I use depend on version of libasound2 that are on the machine now, and installing ia32-libs will force libasound2 and lib32asound2 to be downgraded, forcing reinstall of at least these multimedia packages... SO, I'm willing to do it if it will work.

I've never gotten it to work before.

So what I want to know is, after I install ia32-libs and ia32-libs-gtk, and hypothetically I see on the net somewhere,
" .deb"
with no amd64.deb and no x86-64.deb. Now, how do I install it?

I've tried it, but it tells me it's the wrong architecture (being that it's not amd64). I believe I got that same error back before ia32-libs was removed, although I can't swear to it. Is it that error that the ia32-libs thing prevents?

Along the same lines, I see on the net somewhere:
and upon running it, it complains that it's not meant for a 64-bit architecture. WTH, eh? I have ia32-libs installed, so why the problem? What do I do then to make it recognize it's an i386 compatible machine? Do I have to export variables to the system environment?

Thanks for any help,

Jacksonville, FL, USA

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by Anonymous (85.157.xx.xx) on Sun 24 Jan 2010 at 21:20
Hi. I had this same problem as you had with one proprietary i386 app.

As the program was shipped as ".deb.bin", it was meant to be installed to a 32 bit system. I had to execute this program and it extracted a .deb package then tried to install it using dpkg. I had also installed ia32-libs and ia32-libs-gtk packages and got the same error about wrong architecture. As I know my AMD64 is capable of running both architectures same time, i knew it is theoretically possible to make this work.

I made a working install with adding force-architecture to /etc/dpkg/dpkg.conf file. After this DPKG warns when you install i386 debs, but will go further successfully. The proprietary program works as intended.

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by Anonymous (98.213.xx.xx) on Wed 30 Jun 2010 at 02:07
This worked great for Canon's Pixma IP4700 printer driver. I installed ia32-libs, ia32-libs-gtk and added "force-architecture" to /etc/dpkg/dpkg.cfg.
The driver works perfectly, as it did with i386.

This is off-track, but the package itself is ubuntu and sudo-centric, so I su'd to root, then "sudo ./" (last installation I modified the file.)

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by rainglasz (192.26.xx.xx) on Thu 20 Sep 2012 at 09:52
The instructions to install the missing libraries should be updated,
as in the README points out that the libraries have to be moved after unpack.

So you unpack with dpkg -X xx.deb /somewhere,
note where it its saved below /somewhere,
and then copy or link symbolically /into /usr/lib32

[ Parent ]

Re: Using proprietary i386 apps on an amd64 system
Posted by dkg (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Thu 20 Sep 2012 at 21:35
[ View Weblogs ]
actually, the correct way to use this on modern debian systems is to take advantage of the multiarch capabilities that are built into the operating system.

[ Parent ]