1

I want to run the aapt binary on my shared hosting so that I can use it in some scripts. I have installed aapt locally (sudo apt install aapt), and uploaded it to my home/user/bin folder on shared hosting with execute bit set. When I run it via ssh I get this error:

aapt: error while loading shared libraries: libaapt.so.0: cannot open shared object file: No such file or directory

So I find which library files are required locally for aapt, gather and zip them. Upload and extract them to home/user/lib folder.

zip -j libs.zip $(ldd /usr/bin/aapt | grep "=>" | sed -e "s/(.*//" -e "s/.*=> //")

When I execute aapt now on shared hosting (or any other command for that matter) I get a segmentation fault.

So I move all the library files to home/user/lib/aapt and execute aapt. Each time I get an error for a missing lib file, I move the missing library back up to the home/user/lib folder until I have the following:

lib:
aapt/
lib7z.so
libaapt.so.0
libandroidfw.so.0
libbacktrace.so.0
libbase.so.0
libcutils.so.0
liblog.so.0
libpng16.so.16
libunwind.so.0
libutils.so.0
libziparchive.so.0

lib/aapt:
libc.so.6*
libexpat.so.1
libgcc_s.so.1
libm.so.6
libpthread.so.0*
libstdc++.so.6
libz.so.1

When I run aapt now I get the following errors:

aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by aapt)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by aapt)
aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/user/lib/libaapt.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/libaapt.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libaapt.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /home/user/lib/libutils.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libutils.so.0)
aapt: /lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /home/user/lib/libpng16.so.16)
aapt: /lib64/libz.so.1: version `ZLIB_1.2.3.4' not found (required by /home/user/lib/libpng16.so.16)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libpng16.so.16)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by /home/user/lib/libandroidfw.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /home/user/lib/libandroidfw.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/libandroidfw.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libandroidfw.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by /home/user/lib/liblog.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by /home/user/lib/liblog.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/user/lib/liblog.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/liblog.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/liblog.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libcutils.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /home/user/lib/libcutils.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libbacktrace.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /home/user/lib/libbacktrace.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/libbacktrace.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/user/lib/libbacktrace.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libziparchive.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/libziparchive.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libbase.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /home/user/lib/libbase.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/user/lib/libbase.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/user/lib/libbase.so.0)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/libunwind.so.0)
aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /home/user/lib/lib7z.so)
aapt: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/user/lib/lib7z.so)
aapt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/user/lib/lib7z.so)

If I move the libc.so.6 or libstdc++.so.6 files into the lib folder, I get the segmentation fault again because they interfere with the host system library files which I presume are dependent on another version.

This is where I am stuck and my question is how do I make the aapt binary point to the different libraries in the aapt folder?

I preferably don't want to do any recompiling as a static binary as this is out of my scope of abilities and wish to keep it that way for the time being.

3
  • What's up Mr. Cryptic Sponge Bob.... Could this be an x86 vs x64 type issue? If you have not already considered or looked into that, maybe that's worth a simple look to verify, etc. Cool!! Commented Dec 31, 2018 at 14:55
  • Host is x64 and workstation is x64. Typing uname -mpi gives same result: x86_64 x86_64 x86_64
    – 5p0ng3b0b
    Commented Dec 31, 2018 at 15:00
  • I guess I was referring to the libraries as well as the host and client CPU architecture. I read some issues are resolved by ensuring the x86 libraries are available too (or x64) vice versa where/if/when applicable, etc. But otherwise it may be something like this you are in need of potentially so look it over in case it helps too. . . unix.stackexchange.com/questions/24811/… Commented Dec 31, 2018 at 16:37

2 Answers 2

0

You need to set a LD_LIBRARY_PATH that contains the directory the .so files you uploaded from your local system.

user@host:~$ export LD_LIBRARY_PATH=/home/user/lib/ /path/to/aapt ...

You can check to see if aapt is finding them and if so where using ldd /path/to/appt/binary

But it also looks as if some system .so files are mis-matched versions, so you may have a LOT more file finding an uploading to do from your local system.

3
  • LD_LIBRARY_PATH is already set to /home/user/lib. If I place any library files there, or add another folder to the path, the main system also takes these folders as a priority over existing ones so not an option. I know it is possible to compile a program to look to a specified folder for its libraries, but compiling isn't the route I wish to travel and may as well make a static version.
    – 5p0ng3b0b
    Commented Jan 2, 2019 at 21:55
  • @5p0ng3b0b that is why you change your lib path in one instance of one shell and run your program - rest of system retains default. Good luck!
    – ivanivan
    Commented Jan 2, 2019 at 22:48
  • I am using ssh shell. Still get seg fault when running aapt after changing LD_LIBRARY PATH. Even if It did work running that way, the other commands would seg fault in the script. I have now managed to make a working static binary using ermine but will only last for 30 days. I will persevere!
    – 5p0ng3b0b
    Commented Jan 3, 2019 at 3:41
0

Eventually I got it working! Initially I wrote a script that used apktool to decompile the apk and extract the information that I required (apk label and version number), but the process although functional was rather slow, taking about 5 or 6 seconds per apk. I then discovered a perl module to get aapt running on the host by following instructions here.

You must log in to answer this question.

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