I'm trying to build a C binary for my Oneplus 3T (LogoInjector) which uses a snapdragon 821 so it's a arm64 device.
When I run:
android-ndk-r13b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-gcc -I android-ndk-r13b/platforms/android-24/arch-arm64/usr/include -c LogoInjector.v1.4.c lodepng
and copy the compiled binary to /system/bin on my phone I get this error:
sush: /system/bin/LogoInjector: not executable: 64-bit ELF file
I also tried the 32 bit toolchain but then it gives me:
sush: /system/bin/LogoInjector: not executable: 32-bit ELF file
I set the binary's permission to 755 just like all the others in /system/bin
Can anyone help me fix this?
Thanks!
The -c switch is instructing the compiler to perform the compilation only step, skipping the linkage stage, producing an object file and not executable. Invoke the
aarch64-linux-android-gcc -I android-ndk-r13b/platforms/android-24/arch-arm64/usr/include LogoInjector.v1.4.c -o lodepng
command instead. It is possible that you will need to specify some linker options (like libraries to link with) in addition to these parameters.
I met this issue when trying to run an application.
Try to run command :"file nameapp". Here I get:
ELF executable, 32-bit LSB arm, dynamic (/system/bin/linker), not stripped.
But my board run command:"file system/bin/sh"
ELF shared object, 64-bit LSB x86-64, dynamic(/system/bin/linker64), for Android 27,BuildID=4a49062467e2958e78ce79839f483302, stripped.
It's different so cannot run.
If you want to run it. Get the file with x86-64.
Related
I'm experimenting with native libs cross compiled from ubuntu. What I really want is to be able to compile my c++ libraries and use them in a Xamarin.Android app.
First, I have the arm gcc compiler: arm-linux-gnueabi-gcc. I have a simple lib (libmr.so) that has one function void Print(); that prints something to the console. I'm compiling with:
arm-linux-gnueabi-gcc -Wall -shared -o libmr.so mr.c
When inspecting it using file libmr.so everything seems to be good. However when I'm including it with my android app and try to load it, it is as if it doesn't exist. I'm certain it is there, the path is absolutely correct as I tried to load another lib (libmonodroid.so) from the same folder and it worked.
I tried inspecting both libs to find some kind of a difference:
$ objdump -x libmr.so | grep NEEDED
NEEDED libc.so.6
$ objdump -x libmonodroid.so | grep NEEDED
NEEDED libc.so
... (in addition to other libs)
This is the only difference I'm finding between the two. libmonodroid.so loads properly but libmr.so acts as if it doesn't exist. (I'm using dlopen to load a lib)
EDIT:
I built an executable using the same toolchain, gave me a clue:
Static linking with libc: arm-linux-gnueabi-gcc -Wall -o hi source.c -static. Pushed hi to my android devices and executed it with adb. Result: SUCCESS!
Dynamic linking with libc: arm-linux-gnueabi-gcc -Wall -o hi source.c. Result: it's not even there! Meaning ./hi gives /system/bin/sh: ./hi: not found although it's absolutely there.
So, looks like libc is really the culprit? Maybe I need to link dynamically with not libc.so.6 but with libc.so just like libmonodroid.so is doing?
Check this out for anyone having the same problem. Download the ndk, there's a standalone toolchain for building native libs that run on android that you can extract (you won't need the whole ndk).
I was able to run a basic app on ubuntu 15.04 with this Makefile in the same dir as my hi.c:
$ cat hi.c # create hi.c with favorite editor
#include <stdio.h>
int main(int argc, char** argv) {
int uid = getuid();
int eid = geteuid();
printf("Hello world\n");
printf("You are uid: %d and eid; %d", uid, eid);
return 0;
}
$ cat Makefile # create two line Makefile
CC=arm-linux-gnueabi-gcc
LDFLAGS=-static
$ make hi # build arm based hi executable file
arm-linux-gnueabi-gcc -static hi.c -o hi
$ file hi # check file type
hi: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=17b65e60cdd32449ac237bfd1b8238bfa1d416a0, not stripped
$ adb push hi /data/local/tmp # copy to droid fon
4403 KB/s (593252 bytes in 0.131s)
$ adb shell /data/local/tmp/hi # run hi executable
adb shell /data/local/tmp/hi
Hello world
You are uid: 2000 and eid; 2000
$ uname -a
Linux lenny 3.19.0-28-generic #30-Ubuntu SMP Mon Aug 31 15:52:51 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Note that I do not have any NDK installed.
I wanted to examine the issue from this question: Android NDK for x86_64 has no reference for bcopy and index. In the question, the poster asked about Android x86_64 and bcopy in relation to the Lame sound library.
I set up my cross-compile environment, set the paths for tools and sysroot, and exported the usual suspects like CC, CXX CFLAGS, CXXFLAGS, etc. For example:
$ echo $CC
x86_64-linux-android-gcc
$ which x86_64-linux-android-gcc
/opt/android-ndk-r10d/toolchains/x86_64-4.9/prebuilt/darwin-x86_64/bin/x86_64-linux-android-gcc
And:
$ export CFLAGS="--sysroot=$ANDROID_SYSROOT"
$ echo $CFLAGS
--sysroot=/opt/android-ndk-r10d/platforms/android-21/arch-x86_64
The above is usually enough to get things started. Everything is set correctly, and I can use the script to build other libraries, like Crypto++ and OpenSSL (with some minor adjustments).
However, I have not been able to configure for Android x86_64 (see below). I can't seem to find the right triplet.
What triplet does Android x86_64 use with Autoconf?
Under Autoconf, AC's "build" is what most people consider "host", and AC's "host" is what most people consider "target". So the options are actually correct when cross compiling.
$ ./configure --build=`./config.guess` --host=x86_64-linux-androideabi
checking build system type... i686-apple-darwin12.5.0
checking host system type... Invalid configuration
`x86_64-linux-androideabi': system `androideabi' not recognized
configure: error: /bin/sh ./config.sub x86_64-linux-androideabi failed
$ ./configure --build=`./config.guess` --host=x86_64-linux-android
checking build system type... i686-apple-darwin12.5.0
checking host system type... Invalid configuration
`x86_64-linux-android': system `android' not recognized
configure: error: /bin/sh ./config.sub x86_64-linux-android failed
$ ./configure --build=`./config.guess`
checking build system type... i686-apple-darwin12.5.0
checking host system type... i686-apple-darwin12.5.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... x86_64-linux-android-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/Users/android/lame-3.99.5':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
I fetched autoconf-2.69.tar.xz from the GNU FTP site. I found the latest config.guess and config.sub in the build-aux directory and used it for the LAME MP3 encoder project.
It appears the triplet is x86_64-linux-android.
The project has a broken link though. The invocation of the compiler driver through libtool that creates the shared object lacks CFLAGS, so --sysroot is not passed to the linker. That causes a bunch of link errors due to missing system libraries, like crtbegin_so.o, crtend_so.o, -lc and -ldl.
The fix for that is to manually run the the failed command from the libmp3lame directory. Prepend the command with $CC $CFLAGS <rest of project's command>.
How can I build OpenSSL for Android ARM v7 (using Android NDK) on Win32?
Until the OpenSSL's wiki and setenv-android.sh are updated accordingly, I'll publish the recipe here. The required fixes to the process are:
Update setenv-android.sh to support Windows.
Update PATH to use Android NDK's (mingw) GNU make (rather than Cygwin's).
Invoke make with a Windows-style path to Cygwin's perl.
This recipe will be a strange hybrid of Cygwin and mingw (since Android NDK gcc toolchains for win32 are mingw). I'm assuming a Windows x86_64 build of the Android NDK unpacked into c:\android-ndk-r9d, and that you wish to use a gcc 4.8 toolchain.
Install Android NDK (duh!).
Install Cygwin -- make sure to include perl
Start Cygwin shell as an administrator to make sure native symlinks will work.
Within the console, run the following script to set the variables:
export \
CYGWIN=winsymlinks:native \
ANDROID_API=android-14 \
ANDROID_DEV=c:/android-ndk-r9d/platforms/android-14/arch-arm/usr \
PATH=/cygdrive/c/android-ndk-r9d/prebuilt/windows-x86_64/bin:/cygdrive/c/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/windows-x86_64/bin:$PATH \
MACHINE=armv7 \
SYSTEM=android \
ARCH=arm \
CROSS_COMPILE=arm-linux-androideabi-
Now, unpack openssl:
tar xzfv openssl-1.0.1i.tar.gz (or whatever your tarball is)
cd openssl-1.0.1i (or whatever your version is)
Make sure you have actual native Win32 (!) symlinks in include/openssl:
cmd /c "dir include\openssl"
You should see something like:
13-Aug-14 05:59 PM <SYMLINK> aes.h [..\..\crypto\aes\aes.h]
13-Aug-14 05:59 PM <SYMLINK> asn1.h [..\..\crypto\asn1\asn1.h]
(etc.)
Now it's time to configure:
./config shared -no-ssl2 -no-ssl3 -no-comp -no-hw -no-engine --openssldir=/foo/bar
Ignore the failure to build (due to failure to find perl). We'll rectify this right away. Do this:
make PERL=$(cygpath -w $(which perl))
Now wait for a few minutes until it builds, and presto, you have your libcrypto.so etc.
Just a couple of comments on my experience with this:
Executing this statement:
PERL=$(cygpath -w $(which perl))
in the cygwin shell allows the shell to interpret the backslashes as escape characters and the build process chokes. To solve this I did the following:
$ echo $(cygpath -w $(which perl))
which produced the windows formatted path to the perl executable:
C:\cygwin64\bin\perl
Then I added this line to the export shown above:
PERL=c:/cygwin64/bin/perl \
There are other ways of doing this, but it worked and headed off the problem with the ./config statement documented above (not finding perl).
Second issue was the -no- statements. After running the configure, the script reports that you'll have to run make depend. I wanted to exclude MD5 (i.e. -no-md5) and when I did the make depend, it errored out with a report that MD5 was disabled. Uhhh, yes, that was kind of the idea, but I just won't use MD5 hashes. I did use the -no-ssl2 and didn't get any complaints after the make depend.
Third issue and this is a mystery. The build broke on compiling crypto because it could not find a symbol that is supposed to be defined in /crypto/objects/obj_xref.h. When I looked at the file, it was empty. Something in the perl script I suppose, but no time to debug right now, since I'm at proof of concept phase. I placed a copy from a patch that I picked up at https://github.com/devpack/openssl-android
After that, my build ran to completion. I've done no testing with this and it is not a trustworthy solution, but it did compile and produce the static libraries that I need for proof of concept for my client.
Just as an update, my shared library built with these libraries loaded fine on my target.
As I could not get mksquashfs tool for android. I compiled it for arm using cross compilation and got it built, toolchain is same for kernel as well mksquashfs.
I pushed mksquashfs to /data/ partition of target.
#: cd /data/
#: mkdir xyz
#: ./mksquashfs xyz xyz.sqsh
Error message is:
/system/bin/sh: ./mksquashfs: not executable: magic 7F45
Please let know how to get a working mksquashfs for android, if I am missing any cross compile toolchain etc.
Magic number 7F45 specifies the Executable and Linkable Format (ELF) file type, a format that is not executable on ARM processors.
Reason could be either improper cross compilation or either using wrong toolchain.
Using correct toolchain should fix this problem
I create two standalone ndk compiler arm and x86, and set environment variable of windows, let's say CUSTOM_NDK. When I put arm path to CUSTOM_NDK, and under cygwin command line to compile such as arm-linux-androideabi-gcc -c xxx.cpp, it's working fine. But when I put x86 path to CUSTOM_NDK, close cygwin and reopen it to ensure the env variable is loaded, every time I launch i686-linux-android-gcc -c xxx.cpp, it gives me the following error:
i686-linux-android-gcc.exe: error: CreateProcess: No such file or directory
I use i686-linux-android-gcc --print-search-dirs, it gives me the following which seems correct to me
$ i686-linux-android-gcc -print-search-dirs
install: c:\dev\custom-android-toolchian_x86\bin\../lib/gcc/i686-linux-android/4.6/
programs: =c:/dev/custom-android-toolchian_x86/bin/../libexec/gcc/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../libexec/gcc/;c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/bin/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/bin/
libraries: =c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/;c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/lib/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/lib/;c:/dev/custom-android-toolchian_x86/bin/../sysroot/lib/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../sysroot/lib/;c:/dev/custom-android-toolchian_x86/bin/../sysroot/usr/lib/i686-linux-android/4.6/;c:/dev/custom-android-toolchian_x86/bin/../sysroot/usr/lib/
Any help is much appreciated!
Thanks