Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.
# /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: libz.so.1: cannot open shared object file: No such file or directory

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

share|improve this question

4 Answers 4

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 libz.so.1.2.3 !!

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
   CC="$cc"
-  SFLAGS="${CFLAGS--O3} -fPIC"
-  CFLAGS="${CFLAGS--O3}"
+  SFLAGS="${CFLAGS--O3} -fPIC -m32"
+  CFLAGS="${CFLAGS--O3} -m32"
   if test $build64 -eq 1; then
     CFLAGS="${CFLAGS} -m64"
     SFLAGS="${SFLAGS} -m64"
  • make
  • move libz.so.1.2.5 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

Just try: # emerge emul-linux-x86-baselibs, it will provide the 32bit libz.so.1 ... 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

Your Answer

 
discard

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.