Although the Android Development Tools (ADT) bundle is available as a zip package for 'Linux 64 Bit' it states following requirements:

64-bit distributions must be capable of running 32-bit applications.

And indeed, just running the packaged eclipse on a Fedora 17 64 bit system results in errors, because it can't 'find' several development tools, e.g. adb or aapt:

Error executing aapt: Cannot run program "/home/juser/local/adt-bundle-linux/sdk/platform-tools/aapt": error=2, No such file or directory: error=2, No such file or directory

The 'no such file' is misleading because it is there (under $HOME/local):


But I can't execute it on the shell:

~/local $ ./adt-bundle-linux/sdk/platform-tools/aapt 
zsh: no such file or directory: ./adt-bundle-linux/sdk/platform-tools/aapt

Looking at the file

$ file adt-bundle-linux/sdk/platform-tools/aapt
adt-bundle-linux/sdk/platform-tools/aapt: ELF 32-bit LSB executable, Intel 80386,
 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8,
 not stripped

we see that it is a 32 binary. And it seems that my system (currently) is not capable of running 32-bit applications.

How do I change that? How do I make a current Fedora 64 bit system capable of running 32 bit applications?

(Of course one could also ask why someone ends up putting 32 bit binaries into a binary package called 'Linux 64 bit' ...)


3 Answers 3


With regard to eclipse not being able to find adb, etc, this because without the 32-bit shared libraries needed to run them on the system, they are not executable.

With regard to 32-bit libraries, the situation is fairly simple: you just need to install the appropriate 32-bit libs. On the 64-bit fedora 17 install I have here, the primary 64-bit libraries are in /usr/lib64 and optional 32-bit libs are in /usr/lib. So, if I call ldd on on sdk/platform-tools/adb:

linux-gate.so.1 =>  (0xf7791000)
librt.so.1 => /lib/librt.so.1 (0xf776c000)
libncurses.so.5 => /lib/libncurses.so.5 (0xf7747000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf772d000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7644000)
libm.so.6 => /lib/libm.so.6 (0xf7618000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75fb000)
libc.so.6 => /lib/libc.so.6 (0xf7449000)
/lib/ld-linux.so.2 (0xf7792000)
libdl.so.2 => /lib/libdl.so.2 (0xf7444000)
libtinfo.so.5 => /lib/libtinfo.so.5 (0xf7424000)

Notice these are all in /lib, which is a symlink to /usr/lib (not /usr/lib64). Look:

»file /lib/libc.so.6
/lib/libc.so.6: symbolic link to `libc-2.15.so'
»file /lib/libc-2.15.so
/lib/libc-2.15.so: ELF 32-bit LSB shared object [...]

A 32-bit standard C library. What you can do is go through the 32-bit sdk tools and check to see what they are linked against with ldd. I don't have an example at hand, but if something is missing ldd reports something like:

libc.so.6 => ??????

First, tho, for ldd to work you will need the 32-bit loader that comes with the 32-bit glibc (without this, ldd will call it a non-executable file and tell you nothing):

»yum search glibc
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries

That's truncated, but the x86_64 package is what you have already; the i686 is the 32-bit version. So just install that.

You do not need any of the 'devel' packages, as nothing gets compiled. Beyond that, educated guesses and yum whatprovides / yum search should help (looking at the list for adb, there's also 32-bit versions of the C++ lib, ncurses, pthreads, and a I few things I don't know).

Quick tip about using whatprovides:

»yum whatprovides libtinfo
No matches found.
»yum whatprovides libtinfo.so.5
[2 matches]
»yum whatprovides "*/libtinfo.so.5"
[4 matches]


  • ok, I'll try to install the i686 versions of libraries displayed via ldd. For the reason: I am not convinced, calling file on the bundle version of adb displays: ELF 32-bit LSB executable, Intel 80386 - nothing to do with ARM emulation - and /usr/bin/adb (from the android-tools fedora package) is actually available as ELF 64-bit LSB executable, x86-64. Commented Dec 7, 2012 at 15:16
  • If I call ldd on adt-bundle-linux/sdk/platform-tools/adb it displays 'not a dynamic executable'. Regarding the PATH - this is not the problem - fully specifying the path of e.g. ./adt-bundle-linux/sdk/platform-tools/adb in a terminal does not work (results in 'zsh: no such file or directory [..]'). Commented Dec 7, 2012 at 15:24
  • Do you have glibc.i686 installed yet? Like I said, you (likely) need a 32-bit loader for ldd to work, and that will be with the glibc package. WRT adb being a 32-bit intel arch, that's because that's your system, something compiled for ARM will not work there. However, the same 32-bit stuff could be compiled for ARM, and I imagine parts of it are when used on Android devices. I admit might be wrong about that being the necessity, but in any case, that's what's available, and it is not really that much of a hassle.
    – goldilocks
    Commented Dec 7, 2012 at 15:42
  • WRT the path, maybe it is not necessary for eclipse, and (as you say) you may get the same error on the command line if the file cannot be executed anyway. Just get the libs installed, etc, and you will find out.
    – goldilocks
    Commented Dec 7, 2012 at 15:44
  • 2
    There's no relation between the emulator being a 32-bit program and the emulated platform having a 32-bit processor. The Android emulator is in fact based on Qemu, which can emulate any of armv7 (32-bit), armv8 (64-bit), x86, amd64, mips, mips64, and many more, regardless of the host architecture. Commented Dec 7, 2012 at 22:24

You have to install the 32 bit glibc:

# yum install glibc.i686

This removes the misleading 'no such file or directory' message when trying to execute a 32 bit binary. With that the 64 bit Fedora system is capable of executing 32 bit binaries.

This also removes the misleading 'not a dynamic executable' message of ldd when calling ldd on a 32 bit dynamic executable.

Now you have to install missing 32 bit libraries the binaries under adt-bundle-linux/sdk/platform-tools are linked against:

# yum install zlib.i686 libstdc++.i686 ncurses-libs.i686 libgcc.i686

Thats it.


Some background how to derive the above package names. For example looking at the output of

$ ldd adb
linux-gate.so.1 =>  (0xf774f000)
librt.so.1 => /lib/librt.so.1 (0xf7725000)
libncurses.so.5 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0xf770b000)
libstdc++.so.6 => not found
libm.so.6 => /lib/libm.so.6 (0xf76df000)

means, that 2 libraries are still missing for adb.

For each 'not found' we have to lookup the package name, e.g.:

$ yum whatprovides '*libstdc++.so.6'
libstdc++-4.7.2-2.fc17.i686 : GNU Standard C++ Library

Now we take the package base name and add '.i686' to it to get the 32 bit version.

  • This answer is great, especially the first part - indeed installing glibc.i686 allows ldd to work properly with i386 binaries.
    – Krystian
    Commented Jan 22, 2018 at 13:08

You can install the necessary package with:

sudo yum install redhat-lsb.i686

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .