Linux – Running a 32-bit executable on 64-bit Debian Jessie

32-bit64-bitdebianlinux

I'm trying to install Adobe Air (needed for Balsamiq Mockups), and when I try to run the installer, I get:

sudo: unable to execute ./AdobeAIRInstaller.bin: No such file or directory

I made sure the file is executable, and from googling around, it seems that trying to run a 32-bit executable on a 64-bit system will do that. Everyone's recommandation at this point seems to be to install ia32-libs, however that package is no more in Debian Jessie (they've refactored the multiarch support, it seems).

What do I need to do? multiarch-support is installed, is there something else?

Best Answer

  • Some background

    Yes, ia32-libs was a stop-gap measure before true multi-arch has been implemented—basically, that package merely contained a bunch of 32-bit versions of some popular libraries.

    What you do now is

    1. Enable foregin architecture i386 in dpkg:

      dpkg --add-architecture i386
      
    2. Figure out what libraries this thingy wants and install their appropriate 32-bit (i386) versions, like

      apt-get install libfooX.Y:i386
      

    But note few unfortunate things:

    • Multi-arch in Debian is based on the fact arch-dependent libraries are installed into arch-dependent directories, like /usr/lib/x86_64-linux-gnu for native amd64 libraries and /usr/lib/i386-linux-gnu/ for the same i386 libraries on the same system.

      The problem here is that the third-party software which is unaware of multi-arch as implemented in Debian, typically expects to find libraries it depends on using sort-of-well-known names like /usr/lib/libfoo.so.X.Y.Z, which is simply not the case with recent Debian versions.

      This could be solved with symlinking or LD_PRELOAD or messing with the dynamic loader using some other ways (for instance, making it use an alternative cache file instead of /etc/ld.so.cache, containing references to libraries installed elsewhere) but see the next point.

    • The work on Linux-compatible versions of Adobe Air had been stopped for quite a long time, IIRC, so the latest Adobe Air blob might depend on quite obsoleted versions of libraries not present in recent versions of Debian. And more recent libraries mean API/ABI changes, and these are not solvable using symlinks.

    Possible solution

    If getting rid of this Adobe abomination is impossible, I would possibly try to rely on the fact the Linux kernel's API/ABI is quite stable and try to create a chroot or LXC environment specifically to run this blob using libraries pulled from any OS claimed to be compatible with it.

    Basically, for chroot, you'd need to create a directory containig a minimal set of libraries (and may be some binaries, like /bin/bash) with well-known names (like /usr/lib/libfoo.so).

    This is not exactly an easy way (you'll need a lot of trial-and-error rounds, armed with readelf, ldd, extracting and copying files etc) but it could work out because in the end, all the libraries call out to the kernel using syscalls, and these are pretty stable across kernel releases.

  • Related Question