I would like to compile Android Apps with SDK 23.0.3 as a user on CentOS. Unfortunately, everytime build-tools/23.0.3/aapt is run, it returns
bash: build-tools/23.0.3/aapt: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
The problem seems to be that 32 bit libraries need to be installed. If I have sudo rights (on Ubuntu), I can run sudo apt install libc6-i386 lib32stdc++6 lib32gcc1 (like described in CentOS 64 bit bad ELF interpreter), but unfortunately, I do not have sudo on the machine where I would like to compile.
I assumed that I could get the used libraries (like described in https://www.cs.virginia.edu/~dww4s/articles/ld_linux.html) and then replace the used libraries by setting LD_LIBRARY_PATH (like described in http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html). I extracted the libraries by
ldd ../androidsdk/build-tools/23.0.3/aapt | \
grep "i386" | awk '{print $3}' | \
while read file
do cp $file .
done
and copied them to /home/test. Then I ran export LD_LIBRARY_PATH=/home/test, but then aapt returns the same error.
Another thing I tried was getting and extracting the libraries (on Ubuntu):
apt-get download libc6-i386 lib32stdc++6 lib32gcc1
for file in *.deb
do dpkg -x $file .
done
And aftwards setting the LD_LIBARY_PATH to /home/test/lib:/home/test/lib32, which also did not work.
This could be reproduced by a docker container: running docker run -it ubuntu bash and then
apt update && apt install git unzip wget openjdk-8-jdk
cd home/
wget https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip
unzip sdk-tools-linux-4333796.zip
cd tools/
yes | bin/sdkmanager --install "build-tools;23.0.3"
cd ..
For setup. Then, build-tools/23.0.3/aaptreturns
bash: build-tools/23.0.3/aapt: No such file or directory
which is the same problem as in the CentOS (Can not run android/sdk/build-tools/23.0.2/aapt): A 32 bit library is missing.
Can someone tell me what would be the correct way to add the libraries?
EDIT
Since the interpreter, normally /lib/ld-linux.so.2 starts interpreting files, it needs to be replaced. If I manually extract all .so-files like described above, put them in lib/ and run
LD_LIBRARY_PATH=$(pwd)/libs libs/ld-linux.so.2 build-tools/23.0.3/aapt
the aapt-command is executed correctly. Unfortunately, this is not enough for building:
LD_LIBRARY_PATH=/nfs/user/do820mize/workspaces/dissworkspace/androidsdk/libs /nfs/user/do820mize/workspaces/dissworkspace/androidsdk/libs/ld-linux.so.2 ./gradlew --init-script ../init.gradle assemble
returns the ELF-error again, since the gradle-wrapper (and Java and so on) are 64 bit binaries.
glibc.i686 is available from the base repository:
$ yum whatprovides ld-linux.so.2
glibc-2.17-260.el7.i686 : The GNU libc libraries
Repo : base
Matched from:
Provides : ld-linux.so.2
in case it should not be possible to have basic dependencies provided, that cluster is useless. of course it would need to be installed on all nodes; the chances that it would break something are rather slim, while having the same version number for the x86_64 version of the glibc library.
The problem is, that the header of the elf file (e.g. aapt) contains a link to the interpreter (e.g. /lib/ld-linux.2.so). This link needs to be replaced for execution, but only for the 32 bit elf-binaries. Gradle and Java still need to be executed with their regular 64 bit Interpreter. Since the processes that are called (e.g. aapt) are sub processes, calling another interpreter directly is not possible.
One possible solution is using patchelf (https://nixos.org/patchelf.html). First, it needs to be compiled (even if they say, that there is a binary, I did not find it):
wget https://nixos.org/releases/patchelf/patchelf-0.9/patchelf-0.9.tar.bz2
tar -xvf patchelf-0.9.tar.bz2
cd patchelf-0.9/
./configure && make
Afterwards, you'll find an patchelf executable in src/ (which was a rather surprising location for me).
Just add this to the path by PATH=$(pwd)/src:$PATH, get the ld-linux.so.2 from your system, save it to $MY_PLACE/libs/ld-linux.so.2, cd to your Android SDK and execute
patchelf --set-interpreter $MY_PLACE/libs/ld-linux.so.2 build-tools/23.0.1/aapt
patchelf --set-interpreter $MY_PLACE/libs/ld-linux.so.2 build-tools/23.0.1/aidl
patchelf --set-interpreter $MY_PLACE/libs/ld-linux.so.2 build-tools/23.0.1/zipalign
Then, you'll need to set the library path, e.g. by export LD_LIBRARY_PATH=$MY_PLACE/libs/. Afterwards ./gradlew assemble is running fine (for exactly this build tools version).
While this solution works, you'll need to edit every binary (which may be needed later) manually. I assume that there is some magic in multiarch systems which determines which interpreter to use, the 32 or 64 bit one (ldd will return different pathes for the interpreter depending on the file). It would be a better solution to make use of this magic in order to run 32 bit executables without root. Therefore, I'll accept a solution which make it possible to run builds by just changing environment variables and without tampering with the executables.
Related
I'm trying to build an Alpine image containing the Android SDK - specifically, the platform-tools package.
My Dockerfile does the following:
Installs Java and sets JAVA_HOME (needed for Android).
Downloads the Android SDK tools from Google.
Unzips the package.
Sets ANDROID_HOME. Also sets PATH so the sdkmanager executable can be used.
Installs platform-tools using sdkmanager.
Adds platform-tools to PATH.
platform-tools contains an executable named adb, but for some reason it cannot be seen. Running adb returns:
bash: /android-sdk/platform-tools/adb: No such file or directory
Here is my Dockerfile:
FROM alpine:latest
# Install bash and java
RUN apk update
RUN apk add bash openjdk8
ENV JAVA_HOME=/usr/lib/jvm/java-1.8-openjdk
ENV PATH="$PATH:$JAVA_HOME/bin"
# Download Android SDK and set PATH
RUN mkdir /android-sdk
RUN wget https://dl.google.com/android/repository/sdk-tools-linux-4333796.zip && unzip *.zip -d /android-sdk && rm *.zip
ENV ANDROID_HOME="/android-sdk"
ENV PATH="$PATH:$ANDROID_HOME/tools/bin"
# Install platform-tools
RUN yes | sdkmanager "platform-tools"
ENV PATH="$PATH:$ANDROID_HOME/platform-tools"
RUN adb version # throws error: adb not found
I've looked at this question but the problem should be fixed with platform-tools v24.0 and higher.
Alpine uses musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements.
adb is compiled with glibc, so it won't be able to run in Alpine, which usually results in the error: No such file or directory.
You can verify that a file is compiled with glibc by running file <path to file> | grep "interpreter /lib64/ld-linux-x86-64.so.2".
This may help, although the Gradle daemon randomly crashes for me on Alpine Linux when using the compatibility layer.
gcompat is the go-to compatibility layer for Alpine users.
apk add gcompat
After that you run your binaries as normal.
Source: https://wiki.alpinelinux.org/wiki/Running_glibc_programs
You can install android-tools like so:
RUN apk add \
android-tools \
--repository=http://dl-cdn.alpinelinux.org/alpine/edge/testing
The key is to set the --repository as shown, as it's only in the edge testing repo.
I don't think it includes the whole SDK, so may need to download and unzip as well for other tools. I don't know if this will handle everything you want, but adb prints a help document at least.
I get the latest source code on here :ics-openvpn and I want to compile it under windows environment. As in README.txt said :
Do cd main;./misc/build-native.(sh|bat) in the root directory of the
project. After that build the project using "gradle build" (Or use
Android Studio). The project is converted to gradle and building with
Eclipse is no longer supported.
But the content of file build-native.bat is:
#echo on
echo Currently broken, feel free to fix and send me a patch, see .sh file
exit 1
call ndk-build APP_API=all -j 8
cd libs
mkdir ..\assets
mkdir ..\build\
for /D %%f in (*) do (
copy %%f\minivpn ..\assets\minivpn.%%f
del %%f\libcrypto.so
del %%f\libssl.so
mkdir ..\build\native-libs\%%f\
copy %%f\*.so ..\build\native-libs\%%f\
)
cd ..
it means that author notices that this bat file contains error, that cannot be build by this. I try to remove first three lines and run again, i meet these errors:
main//jni/Android.mk:11: lzo/Android.mk: no such file or directory
main/jni/android.mk : 12: snappy/Android.mk : no such file or
directory ...
so, my question is : can we build this library on windows (because author has notified that this build file is error), and if can, how ?
Thanks :)
It is just like the text says. It is broken because I don't develop on Windows. You can look at the build-native.sh fix the paths etc for Windows. The build problems are nothing difficult but someone has to take the 10 minutes and fix it.
I got all sorts of errors using Cygwin to build this.
You may have more luck using an actual Linux box or something like VirtualBox with an Ubuntu image.
This worked for me. You will need the Linux NDK (installation instructions here) and you'll need to install make with sudo apt-get install make.
Then run cd main;./misc/build-native.sh from the project root.
I'm trying to compile ffmpeg for Android using this guy script (https://github.com/guardianproject/android-ffmpeg) because it looked like the simplest and the whole NDK is really not my area of expertise.
So let's see what I've done so far:
Downloaded and installed a fresh Ubuntu 12.04 LTS from: http://www.ubuntu.com/download/desktop in a VirtualBox. (had some little problems with video but a few updates later in the terminal ubuntu is up and running)
installed the Android SDk and downloded/unzipped the NDK into /Documents/ndk
I used those commands to install the compiler:
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install build-essential
$ gcc -v
$ make -v
then sudo install git (or something like that to install git)
then git clone https://github.com/guardianproject/android-ffmpeg.git
then copied from the guys page building section
cd android-ffmpeg
git submodule init
git submodule update
NDK_BASE=/path/to/android-ndk ./configure_make_everything.sh
it mostly goes well until it says:
arm-linux-androideabi-gcc is unable to create an executable file C
compiler test failed
If you think configure made a mistake,.. blaah blahh blaah
I'm not sure what it means or where to go from here.
from this I did some chmod 777 on the folders to make sure stuff can be execute.
also from this I tried his script but without any luck.
help?
decompose what the script 'config_make_everything' is doing.. and run one step at a time...
https://github.com/guardianproject/android-ffmpeg/blob/master/configure_make_everything.sh
each step will create a file like 'config.log' where you can go to the tail and find more details about what went wrong finding the compiler.
When u start using the NDK, IMO, invest a bit of learn curve time going thru its ./doc directory and making sure that you have it integrated correctly. With NDK install, there are some samples. Build a few from CLI just to make sure that the ENV is correct and that the install is good, and that u have at least some idea of the build as a repeatable process. That will prove that you can do good 'cross compiles' with the build tools. Then you can return to guardian.ffmpeg stuff.
IMO - there is alot going on with an NDK build of this project and getting it all to build without understanding any of the underlying configuration / build stack would require lots of luck.
I'm trying to setup Android development with Eclipse (Indigo), on Fedora17.
Almost everything seems to work, just the javah is missing, to build the C headers with, for native (NDK / JNI) modules.
On my windows install of the tool chain it was in the same folder javac was in, but this is not the case on the Linux machine.
I previously installed Oracle's JDK1.7, found out that it's to new for something else I wanted to do (but also there, no javah), uninstalled it, now JDK1.6 is installed.
What might be wrong?
In linux machines, JavaH is normally located in /usr/bin/javah.
If you try to find this file with locate, it is normally a good idea to run before updatedb, since the database is not updated unless this command is run either by the user or a cron job. You could try finding the file with find / |grep javah
P.S. Sorry to post this as an asnwer. I suppose the corret way to go would have been a comment, but still don't have enough reputation to post a comment
This tool has been removed from the JDK
https://openjdk.java.net/jeps/313
Try gjavah rather than javah?
It turns out that javah link is not created during JDK install. You have to create it manually:
Check where is installed java:
$ ls -l `which java`
lrwxrwxrwx root root 26 15 juil. 02:05 /usr/bin/java -> /usr/java/default/bin/java
Create the symlink in the same directory:
$ su
# cd /usr/bin
# ln -s /usr/java/default/bin/javah
I'm using Python 2.7.2 on Ubuntu 11.10. I got this error when importing the bz2 module:
ImportError: No module named bz2
I thought the bz2 module is supposed to come with Python 2.7. How can I fix this problem?
EDIT: I think I previously installed Python 2.7.2 by compiling from source. Probably at that point I didn't have libbz2-dev and so the bz2 module is not installed. Now, I'm hoping to install Python2.7 through
sudo apt-get install python2.7
But it will say it's already installed. Is there a way to uninstall the previous Python2.7 installation and reinstall?
I meet the same problem, here's my solution.
The reason of import error is while you are building python, system couldn't find the bz2 headers and skipped building bz2 module.
Install them on Ubuntu/Debian:
sudo apt-get install libbz2-dev
Fedora:
sudo yum install bzip2-devel
and then rebuild python
comes from another answer
#birryree's answer helps to back to the system's original python.
Okay, this is much easier to understand in answer form, so I'll move what I would write in my comment to this answer.
Luckily for you, you didn't overwrite the system version of python, as Ubuntu 11.10 comes with 2.7.2 preinstalled.
Your python binaries (python and python2.7) are located in /usr/local/bin, which is a directory where user-specific stuff is usually installed. This is fine, it means your system python is still there.
First, just try to run the system python. Type this from the command line:
/usr/bin/python -c "import bz2; print bz2.__doc__"
This should print out something like this:
λ > /usr/bin/python -c "import bz2; print bz2.__doc__"
The python bz2 module provides a comprehensive interface for
the bz2 compression library. It implements a complete file
interface, one shot (de)compression functions, and types for
sequential (de)compression.
If so, means you're fine.
So you just have to fix your PATH, which tells the shell where to find commands. /usr/local/bin is going to have priority over /usr/local, so there are some ways to fix this, in order of difficulty/annoyance/altering your system:
Remove the symlink python from /usr/local/bin
This will make it so that when you type python, it should go back to executing /usr/bin/python, which is an alias for the system's python 2.7.2.
sudo rm /usr/local/bin/python
Move /usr/bin to have higher precedence in the PATH
Might not be desirable if you already have stuff in /usr/local/bin that should have precedence over /usr/bin, but I'm adding this for completeness.
In your shell profile (not sure what Ubuntu's default is, but I'm using ~/.bash_profile, you can do this:
export PATH=/usr/bin:$PATH
Remove your python install
This is extreme and the first option I presented should be your first option.
Do you really need your own version of Python? If you want isolated python environments you probably really want virtualenv. You can probably remove yours unless there's a reason not to.
It's going to be a little annoying though, but basically:
Remove the python and python2.7 and pythonw and pythonw2.7 commands from /usr/local/bin.
Remove /usr/local/lib/python/2.7.2
This part is not complete because I forget what else there is.
In case, you must be used python2.7, you should run: (Centos 6.4)
sudo cp /usr/lib64/python2.6/lib-dynload/bz2.so /usr/local/lib/python2.7/
Maybe it will helps someone:
apt-get install libbz2-dev # for bz2
apt-get install libssl-dev # for _ssl
apt-get install libsqlite3-dev # for sqlite
apt-get install libreadline6-dev # for readline, _curses, _curses_panel
For Ubuntu/Debian:
sudo apt-get install libbz2-dev
For Fedora:
sudo yum install bzip2-devel
And then recompile the python and install it.
matocnhoi's answer works for me in centOS
sudo cp /usr/lib64/python2.6/lib-dynload/bz2.so /usr/local/lib/python2.7/
and I used virtualenv, so the command is
sudo cp /usr/lib64/python2.6/lib-dynload/bz2.so ../../../env/lib/python2.7/
I used a symlink between /usr/lib64/python2.6/lib-dynload/bz2.so /usr/local/lib/python2.7/lib-dynload/
Worked fine for me...
Make sure you bz2 installed, run sudo yum install bzip2-devel.
Centos 6
sudo cp /usr/lib64/python2.6/lib-dynload/bz2.so /python_install_path/lib/python2.7
Centos 7
sudo cp /usr/lib64/python2.7/lib-dynload/bz2.so /python_install_path/lib/python2.7
python_install_path usually is /usr/local/lib/python2.7/, you need replace that if you install python in a another path.
If your bz2 in /usr/lib64/python2.7/lib-dynload/ is named as: "bz2.x86_64-linux-gnu.so", remember to rename it to bz2.so when copying it to your path or it may not be correctly sourced:
cp /usr/lib64/python2.6/lib-dynload/bz2.x86_64-linux-gnu.so /python_install_path/lib/python2.7/bz2.so
I had the same problem with Python 2.17.15 and pyenv on Ubuntu. System python from /usr/bin/python worked fine. In my case it helped to install libbz2-dev and then to reinstall python 2.7.15:
sudo apt-get install libbz2-dev
pyenv uninstall 2.7.15
pyenv install 2.7.15