Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
# /opt/dev/android-sdk/platforms/android-1.5/tools/aapt
/opt/dev/android-sdk/platforms/android-1.5/tools/aapt: error while loading shared libraries: cannot open shared object file: No such file or directory

On an i386 box this aapt launches, but not on amd64. /lib/ is there in both cases. How come?

share|improve this question

Just try: # emerge emul-linux-x86-baselibs, it will provide the 32bit ... if this fails try ldd /path/to/aapt and provide the output, as well as the output of your ldconfig -v | grep libz

share|improve this answer
Worked for me.. Jenkins was complaining about absent on gentoo server. – southerton Jan 6 '15 at 17:38

It looks like the SDK aapt tool is a 32-bit binary, so it's looking for the 32-bit version of the libz library but only finding the 64-bit. You can check this with ldd. I believe if you install the emul-linux-x86-baselibs package it will give you the correct library in /usr/lib32.

share|improve this answer
up vote 1 down vote accepted

I've looked at dev-util/android-sdk and turns out it's pulling app-emulation/emul-linux-x86-gtklibs as a dependency.

share|improve this answer

the bug is indeed in emul-linux's 32bit !!

i just built a 32bit libz version myself and it works - aapt does not throw the above error. if you are using gentoo - all libz versions of emul-linux-x86-baselibs have this problem (currently 20100915-r1 and 20110129)

here are the steps you need until an updated version of emul-linux-baselibs is out:

  • get zlib (1.2.5 is ok)
  • unpack
  • edit configure
--- configure.old       2011-02-25 03:03:37.739491008 +0100
+++ configure   2011-02-25 03:03:51.760491008 +0100
@@ -105,8 +105,8 @@

 if test "$gcc" -eq 1 && ($cc -c $cflags $test.c) 2>/dev/null; then
+  SFLAGS="${CFLAGS--O3} -fPIC -m32"
+  CFLAGS="${CFLAGS--O3} -m32"
   if test $build64 -eq 1; then
     CFLAGS="${CFLAGS} -m64"
     SFLAGS="${SFLAGS} -m64"
  • make
  • move to /lib32

The Problem is, that while the 64bit version you compile yourself has the following fields in the ELF header:

  [ 5] .gnu.version      VERSYM           00000000000017be  000017be
  [ 6] .gnu.version_d    VERDEF           0000000000001890  00001890
  [ 7] .gnu.version_r    VERNEED          00000000000019e8  000019e8

the 32bit version provided by current emul-linux-x86-baselibs lacks the VERDEF field, it contains only

  [ 4] .gnu.version      VERSYM          00000d9c 000d9c 0000b4 02   A  2   0  2
  [ 5] .gnu.version_r    VERNEED         00000e50 000e50 000050 00   A  3   1  4

you can check yourself whether your custom build of 32bit lib has the VERDEF field - mine does and I wonder why it is missing in the emul-linux distribution..

regards, cmuelle8

ps: sometimes the error messages printed by computer programs is right..

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.