1
# /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?

4 Answers 4

1

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.

1

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

1

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

1
  • Worked for me.. Jenkins was complaining about absent libz.so on gentoo server.
    – Kurovsky
    Jan 6, 2015 at 17:38
1

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..

You must log in to answer this question.

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