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