Develop Reference

How to use cmake from command line to make an executable for rooted Android device?

I want to run a simple executable that should print "Hello Cmake" when I will execute it from adb shell. For this, I have created a simple c++ file with CMakeLists.txt file as following:
hello.cpp
#include <iostream>
int main(int, char**) {
std::cout << "Hello, CMake!\n";
}
CMakeLists.txt
cmake_minimum_required(VERSION 3.4.1)
add_library( # Sets the name of the library.
hello_cmake
# Sets the library as a static library.
STATIC
# Provides a relative path to your source file(s).
hello.cpp )
I have tried to run following command in terminal:
cmake D:/Development/CMAKE/HelloCmake/ -G Ninja \
-DANDROID_TOOLCHAIN_NAME=aarch64-linux-android29-clang++ \
-DANDROID_PLATFORM=29 \
-DCMAKE_CACHEFILE_DIR=D:/Development/CMAKE/HelloCmake/build \
-DCMAKE_MAKE_PROGRAM=D:/Sdk/cmake/3.10.2.4988404/bin/ninja.exe \
-DCMAKE_C_COMPILER=D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang \
-DCMAKE_CXX_COMPILER=D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang++
This has the following result:
D:\Development\CMAKE\HelloCmake>cmake D:/Development/CMAKE/HelloCmake/ -G Ninja -DANDROID_TOOLCHAIN_NAME=aarch64-linux-android29-clang++ -DANDROID_PLATFORM=29 -DCMAKE_CACHEFILE_DIR=D:/Development/CMAKE/HelloCmake/build -DCMAKE_MAKE_PROGRAM=D:/Sdk/cmake/3.10.2.4988404/bin/ninja.exe -DCMAKE_C_COMPILER=D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang -DCMAKE_CXX_COMPILER=D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang++
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang
-- Check for working C compiler: D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang -- broken
CMake Error at D:/Sdk/cmake/3.10.2.4988404/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"D:/Sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android29-clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: D:/Development/CMAKE/HelloCmake/CMakeFiles/CMakeTmp
Run Build Command:"D:/Sdk/cmake/3.10.2.4988404/bin/ninja.exe" "cmTC_e4775"
ninja: fatal: CreateProcess: %1 is not a valid Win32 application.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt
-- Configuring incomplete, errors occurred!
See also "D:/Development/CMAKE/HelloCmake/CMakeFiles/CMakeOutput.log".
See also "D:/Development/CMAKE/HelloCmake/CMakeFiles/CMakeError.log".
D:\Development\CMAKE\HelloCmake>
Please help me to configure it correctly.
Update 1
With Michael guidance, I have found the build_command.txt file in Android Studio and it has the following contents for simple "Hello World" application:
Executable : D:\Sdk\cmake\3.10.2.4988404\bin\cmake.exe
arguments :
-HD:\Development\Android\HelloCPP\app\src\main\cpp
-BD:\Development\Android\HelloCPP\app\.cxx\cmake\debug\arm64-v8a
-DANDROID_ABI=arm64-v8a
-DANDROID_PLATFORM=android-26
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=D:\Development\Android\HelloCPP\app\build\intermediates\cmake\debug\obj\arm64-v8a
-DCMAKE_BUILD_TYPE=Debug
-DANDROID_NDK=D:\Sdk\ndk\20.1.5948944
-DCMAKE_CXX_FLAGS=-std=c++14
-DCMAKE_SYSTEM_NAME=Android
-DCMAKE_ANDROID_ARCH_ABI=arm64-v8a
-DCMAKE_SYSTEM_VERSION=26
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
-DCMAKE_ANDROID_NDK=D:\Sdk\ndk\20.1.5948944
-DCMAKE_TOOLCHAIN_FILE=D:\Sdk\ndk\20.1.5948944\build\cmake\android.toolchain.cmake
-G Ninja
-DCMAKE_MAKE_PROGRAM=D:\Sdk\cmake\3.10.2.4988404\bin\ninja.exe
jvmArgs :
I have run the following command for my application:
D:\Sdk\cmake\3.10.2.4988404\bin\cmake.exe
-HD:\Development\CMAKE\HelloCmake\
-BD:\Development\CMAKE\HelloCmake\arm64-v8a
-DANDROID_ABI=arm64-v8a
-DANDROID_PLATFORM=android-29
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=D:\Development\CMAKE\HelloCmake\build
-DCMAKE_BUILD_TYPE=Debug
-DANDROID_NDK=D:\Sdk\ndk\20.1.5948944
-DCMAKE_CXX_FLAGS=-std=c++14
-DCMAKE_SYSTEM_NAME=Android
-DCMAKE_ANDROID_ARCH_ABI=arm64-v8a
-DCMAKE_SYSTEM_VERSION=26
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
-DCMAKE_ANDROID_NDK=D:\Sdk\ndk\20.1.5948944
-DCMAKE_TOOLCHAIN_FILE=D:\Sdk\ndk\20.1.5948944\build\cmake\android.toolchain.cmake
-G Ninja
-DCMAKE_MAKE_PROGRAM=D:\Sdk\cmake\3.10.2.4988404\bin\ninja.exe
and I get the following output:
D:\Development\CMAKE\HelloCmake>D:\Sdk\cmake\3.10.2.4988404\bin\cmake.exe -HD:\Development\CMAKE\HelloCmake\ -BD:\Development\CMAKE\HelloCmake\arm64-v8a -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=android-29 -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=D:\Development\CMAKE\HelloCmake\build -DCMAKE_BUILD_TYPE=Debug -DANDROID_NDK=D:\Sdk\ndk\20.1.5948944 -DCMAKE_CXX_FLAGS=-std=c++14 -DCMAKE_SYSTEM_NAME=Android -DCMAKE_ANDROID_ARCH_ABI=arm64-v8a -DCMAKE_SYSTEM_VERSION=26 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_ANDROID_NDK=D:\Sdk\ndk\20.1.5948944 -DCMAKE_TOOLCHAIN_FILE=D:\Sdk\ndk\20.1.5948944\build\cmake\android.toolchain.cmake -G Ninja -DCMAKE_MAKE_PROGRAM=D:\Sdk\cmake\3.10.2.4988404\bin\ninja.exe
-- Check for working C compiler: D:/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- Check for working C compiler: D:/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: D:/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
-- Check for working CXX compiler: D:/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: D:/Development/CMAKE/HelloCmake/arm64-v8a
D:\Development\CMAKE\HelloCmake>
Build files are written to arm64-v8a but I didn't find any ELF shared object, 64-bit LSB arm64, dynamic (/system/bin/linker64), stripped object that should be able to run on my android device.
I have found only the following files:
$ find . | xargs file | grep ELF
./CMakeFiles/3.10.2/CMakeDetermineCompilerABI_C.bin: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, BuildID[sha1]=7cb1fddcd4776716628feaf37d471c1ea4a55314, with debug_info, not stripped
./CMakeFiles/3.10.2/CMakeDetermineCompilerABI_CXX.bin: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, BuildID[sha1]=1f498297f62e5a52751312894e88a9abef0412d5, with debug_info, not stripped
./CMakeFiles/feature_tests.bin: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, BuildID[sha1]=a56baeb98e3f077c3cc0a512b0535089a717929c, with debug_info, not stripped
Any suggestion?
Update 2
I have run D:\Sdk\cmake\3.10.2.4988404\bin\ninja.exe -C arm64-v8a command to make the target static library but I get libhello_cmake.a which is current ar archive.
I think to make an executable the CMakeLists.txt add_library line should be replaced with something else?

There are a couple of problems:
Static libraries are not meant to be run directly. If you want to build an executable that you can run, you should use add_executable instead of add_library.
When you invoke cmake you should set the CMAKE_TOOLCHAIN_FILE option to specify the toolchain file to use, and possibly other options as well. To get an idea of what Android Studio / Gradle uses, you can use Android Studio's project wizard to create an Android project with C++ support and take a look at the cmake_build_command.txt file that gets generated when you build that project.
After running cmake you also need to run ninja. The command would be something like ninja -C <directory containing build files generated by cmake>.

Unable to run dynamically cross compiled application on arm device [duplicate]

I've two files:
lib.c
#include<stdio.h>
void hi() {
printf("Hi i'm a library function in lib.so\n");
}
and main.c
#include<stdio.h>
#include<dlfcn.h>
/* based on Jeff Scudder's code */
int main() {
void *SharedObjectFile;
void (*hi)();
// Load the shared libary;
SharedObjectFile = dlopen("./lib.so", RTLD_LAZY);
// Obtain the address of a function in the shared library.
ciao = dlsym(SharedObjectFile, "hi");
// Use the dynamically loaded function.
(*hi)();
dlclose(SharedObjectFile);
}
And I've tried to build an executables using the following commands:
export LD_LIBRARY_PATH=pwd
gcc -c -fpic lib.c
gcc -shared -lc -o lib.so lib.o
gcc main.c -ldl
And it works pretty well.
Then I've tried to export my program on Android (Nexus One, with ARM-v7-0a arch) using the following commands:
export LD_LIBRARY_PATH=pwd
arm-none-linux-gnueabi-gcc -c -fpic lib.c
arm-none-linux-gnueabi-gcc -shared -lc -o lib.so lib.o
arm-none-linux-gnueabi-gcc main.c -ldl -o main
adb push main /system/app
The result of executing ./main on the correct folder on my smartphone is just:
./main: not found
even if my file is right there!
Am I missing anything during the cross-compile process? Any help?
I'm using the cross-compiler from CodeSourcery and it works well for static programs without .so libraries.
Thanks
EDIT: as Igor states below, that was a linker issue. This command fixes it:
arm-none-linux-gnueabi-gcc -o test main.c -Wl,--dynamic-linker=/system/bin/linker -ldl
in my very case I need other libraries because in /system/lib/ there are no many .so files.

The "not found" message refers not to the shared object but to the dynamic linker. Linux uses /lib/ld-linux.so.2 (or /lib64/ld-linux-x86-64.so.2 for x64) while Android uses /bin/linker. You can check which dynamic loader your program uses with readelf -l, e.g.:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
You can specify a linker to use with ld's --dynamic-linker switch, but there are likely to be other differences. For example, Android uses a stripped-down libc implementation called bionic, and it may be missing functionality that your program relies on, or have different behavior.
You should use NDK or another Android-targeted toolchain when compiling programs for Android. Even though it's based on Linux kernel, the differences are large enough that Linux-targeted toolchains are not sufficient.

Entangled with Google test

I am having trouble to get up and running with Google test. I have read the suggested steps from Google, I also looked a previous post, and read some other examples, but it doesn't clear much things up.
To keep things simple, I am trying the suggested example from Google test that is available from the directory in the Android ndk - sample1:
// main.cpp
#include <QtGui/QGuiApplication>
#include "qtquick2applicationviewer.h"
#include "gtest/gtest.h"
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
testing::InitGoogleTest(&argc, argv);
QtQuick2ApplicationViewer viewer;
viewer.setMainQmlFile(QStringLiteral("qml/factorial/main.qml"));
viewer.showExpanded();
return RUN_ALL_TESTS();
}
// sample1_unittest.cpp
#include <limits.h>
#include "sample1.h"
#include "gtest/gtest.h"
// Tests factorial of 0.
TEST(FactorialTest, Zero) {
EXPECT_EQ(1, Factorial(0));
}
The files sample1.h, sample1.cpp are also in the project, which contain the factorial function. Google test was equally informed to the project file - factorial.pro:
INCLUDEPATH +=
/opt/android-studio/ndk/sources/third_party/googletest/googletest/include
When I press [Build > Build Project "factorial"] it gets the following error:
main.cpp:8: error: undefined reference to 'testing::InitGoogleTest(int*, char**)'
sample1_unittest.cpp:17: error: undefined reference to 'testing::Test::Test()'
I am working with Ubuntu, QtCreator, Android and C++. Indeed I have spent already 3 days mocking around, but getting not much anywhere so far. Thus, I am posting here in hope some guru may give any hint on this. Any help will be mostly appreciated.

It seems you haven't built Google Test from what you describe. You need to compile the project into a library and then link against it. If you have CMake installed, then you have two options:
Use CMake's GUI (it's fairly intuitive) to generate the build system files, and then use those as usual (e.g. if you generate a Visual Studio solution, open the .sln file and build the project).
Use the command line to do the same thing; essentially you just create a new directory and do cmake <path-to-google-test> inside of it. The rest is the same.
You could also build the library by yourself. The distribution contains a folder named fused-src which should contain at least two files: gtest_main.cpp and gtest-all.cpp. Compile those files and you're done. You need to generate two libraries here: gtest out of gtest-all.cpp and gtest_main out of gtest_main.cpp.
Another alternative would be to get already built libraries. I've never searched for them, but they might be out there.

Try something like this:
$ g++ -I $GTEST_HOME/include -L $GTEST_HOME/lib -lgtest -lgtest_main -lpthread test.cpp
For more details:
How to setup googleTest as a shared library on Linux
If it still doesn't work, may find interesting to consider to use Makefile:
# A sample Makefile for building Google Test and using it in user
# tests. Please tweak it to suit your environment and project. You
# may want to move it to your project's root directory.
#
# SYNOPSIS:
#
# make [all] - makes everything.
# make TARGET - makes the given target.
# make clean - removes all files generated by make.
# Please tweak the following variable definitions as needed by your
# project, except GTEST_HEADERS, which you can use in your own targets
# but shouldn't modify.
# Points to the root of Google Test, relative to where this file is.
# Remember to tweak this if you move this file.
GTEST_DIR = ..
# Where to find user code.
USER_DIR = ../samples
# Flags passed to the preprocessor.
# Set Google Test's header directory as a system directory, such that
# the compiler doesn't generate warnings in Google Test headers.
CPPFLAGS += -isystem $(GTEST_DIR)/include
# Flags passed to the C++ compiler.
CXXFLAGS += -g -Wall -Wextra -pthread
# All tests produced by this Makefile. Remember to add new tests you
# created to the list.
TESTS = sample1_unittest
# All Google Test headers. Usually you shouldn't change this
# definition.
GTEST_HEADERS = $(GTEST_DIR)/include/gtest/*.h \
$(GTEST_DIR)/include/gtest/internal/*.h
# House-keeping build targets.
all : $(TESTS)
clean :
rm -f $(TESTS) gtest.a gtest_main.a *.o
# Builds gtest.a and gtest_main.a.
# Usually you shouldn't tweak such internal variables, indicated by a
# trailing _.
GTEST_SRCS_ = $(GTEST_DIR)/src/*.cc $(GTEST_DIR)/src/*.h $(GTEST_HEADERS)
# For simplicity and to avoid depending on Google Test's
# implementation details, the dependencies specified below are
# conservative and not optimized. This is fine as Google Test
# compiles fast and for ordinary users its source rarely changes.
gtest-all.o : $(GTEST_SRCS_)
$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c \
$(GTEST_DIR)/src/gtest-all.cc
gtest_main.o : $(GTEST_SRCS_)
$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c \
$(GTEST_DIR)/src/gtest_main.cc
gtest.a : gtest-all.o
$(AR) $(ARFLAGS) $# $^
gtest_main.a : gtest-all.o gtest_main.o
$(AR) $(ARFLAGS) $# $^
# Builds a sample test. A test should link with either gtest.a or
# gtest_main.a, depending on whether it defines its own main()
# function.
sample1.o : $(USER_DIR)/sample1.cc $(USER_DIR)/sample1.h $(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/sample1.cc
sample1_unittest.o : $(USER_DIR)/sample1_unittest.cc \
$(USER_DIR)/sample1.h $(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/sample1_unittest.cc
sample1_unittest : sample1.o sample1_unittest.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $#
If you have to use Makefile to get gtest working, you probably may need to adjust the given template for your case, as you intend to build it to use with Android.

Error during Cross-compiling C code with Dynamic libraries

I've two files:
lib.c
#include<stdio.h>
void hi() {
printf("Hi i'm a library function in lib.so\n");
}
and main.c
#include<stdio.h>
#include<dlfcn.h>
/* based on Jeff Scudder's code */
int main() {
void *SharedObjectFile;
void (*hi)();
// Load the shared libary;
SharedObjectFile = dlopen("./lib.so", RTLD_LAZY);
// Obtain the address of a function in the shared library.
ciao = dlsym(SharedObjectFile, "hi");
// Use the dynamically loaded function.
(*hi)();
dlclose(SharedObjectFile);
}
And I've tried to build an executables using the following commands:
export LD_LIBRARY_PATH=pwd
gcc -c -fpic lib.c
gcc -shared -lc -o lib.so lib.o
gcc main.c -ldl
And it works pretty well.
Then I've tried to export my program on Android (Nexus One, with ARM-v7-0a arch) using the following commands:
export LD_LIBRARY_PATH=pwd
arm-none-linux-gnueabi-gcc -c -fpic lib.c
arm-none-linux-gnueabi-gcc -shared -lc -o lib.so lib.o
arm-none-linux-gnueabi-gcc main.c -ldl -o main
adb push main /system/app
The result of executing ./main on the correct folder on my smartphone is just:
./main: not found
even if my file is right there!
Am I missing anything during the cross-compile process? Any help?
I'm using the cross-compiler from CodeSourcery and it works well for static programs without .so libraries.
Thanks
EDIT: as Igor states below, that was a linker issue. This command fixes it:
arm-none-linux-gnueabi-gcc -o test main.c -Wl,--dynamic-linker=/system/bin/linker -ldl
in my very case I need other libraries because in /system/lib/ there are no many .so files.

The "not found" message refers not to the shared object but to the dynamic linker. Linux uses /lib/ld-linux.so.2 (or /lib64/ld-linux-x86-64.so.2 for x64) while Android uses /bin/linker. You can check which dynamic loader your program uses with readelf -l, e.g.:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
You can specify a linker to use with ld's --dynamic-linker switch, but there are likely to be other differences. For example, Android uses a stripped-down libc implementation called bionic, and it may be missing functionality that your program relies on, or have different behavior.
You should use NDK or another Android-targeted toolchain when compiling programs for Android. Even though it's based on Linux kernel, the differences are large enough that Linux-targeted toolchains are not sufficient.

Want to compile native Android binary I can run in terminal on the phone

I've been trying for a couple days to compile a native ARM Android binary that will execute on my phone using a terminal application. I want to generate the same type of binary as the standard Posix binaries installed on the phone like ls, mkdir etc. I've downloaded the Android NDK under Mac OS X and have been able to compile simple ELF binaries without errors. However, when I transfer them to the phone, they always segfault. That is, they segfault when compiled with -static in GCC. If I don't use -static, they complain about not being linked, etc. Put simply, they don't work.
My hypothesis is that they are not linking to the Android standard C library properly. Even though I am linking my binaries with the libc provided by the NDK, they still don't work. I read that Android uses the Bionic C library, and tried to download source for it but I'm not sure how to build a library from it (it's all ARM assembly, it seems).
Is it true that the Android C library on the phone is different from the one provided with the Android NDK? Will the one included with the NDK not allow me to compile native binaries I can execute through a terminal? Any guidance here is greatly appreciated!
Update:
I finally got this to work using GCC 4.7.0 on Mac OS X. I downloaded the Bionic headers and then compiled a dynamically linked binary using the C library that comes with the Android NDK. I was able to get a test app to work on the phone using the phone's C lib (the binary was 33K). I also tried to statically link against the NDK's C library, and that also worked.
In order to get this all working I had to pass -nostdlib to GCC and then manually add crtbegin_dynamic.o and crtend_android.o to GCC's command line. It works something like this:
$CC \
$NDK_PATH/usr/lib/crtbegin_dynamic.o \
hello.c -o hello \
$CFLAGS \
$NDK_PATH/usr/lib/crtend_android.o
For static binaries, use "crtbegin_static.o." This is explained in the crtbegin_dynamic.S/crtbegin_static.S source.
For this experiment, I only used plain 'ol GCC 4.7.0 and Binutils 2.22. I also compiled GCC with newlib, but I am not actually linking my ARM binaries with newlib at all. I am forcing GCC/ld to link directly to the libc provided with the Android NDK, or in the case of dynamic binaries, to the libc on the phone.

Just use the android-ndk. And build a Android.mk like so.
include $(BUILD_EXECUTABLE) is what tells it build a executable instead of a JNI .lib
Android.mk
ifneq ($(TARGET_SIMULATOR),true)
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_CFLAGS += -Wall
LOCAL_LDLIBS := -L$(LOCAL_PATH)/lib -llog -g
LOCAL_C_INCLUDES := bionic
LOCAL_C_INCLUDES += $(LOCAL_PATH)/include
LOCAL_SRC_FILES:= main.cpp
LOCAL_MODULE := mycmd
include $(BUILD_EXECUTABLE)
endif # TARGET_SIMULATOR != true

First, make sure you have the NDK:
http://developer.android.com/tools/sdk/ndk/index.html
Here is the easiest way to compile a C binary for your phone:
http://developer.android.com/tools/sdk/ndk/index.html
http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html
Usually $NDK(may be different) =
Linux:
/home/<user>/android-ndk
Mac OS X:
/Users/<user>/android-ndk
In Terminal:
# create tool-chain - one line
# New method in ndk 12.
$NDK/build/tools/make_standalone_toolchain.py --arch arm --install-dir=/tmp/my-android-toolchain
# Old method.
#$NDK/build/tools/make-standalone-toolchain.sh --platform=android-3 --install-dir=/tmp/my-android-toolchain
# add to terminal PATH variable
export PATH=/tmp/my-android-toolchain/bin:$PATH
# make alias CC be the new gcc binary
export CC=arm-linux-androideabi-gcc
# compile your C code(I tried hello world)
$CC -o foo.o -c foo.c
# push binary to phone
adb push foo.o /data/local/tmp
# execute binary
adb /data/local/tmp/foo.o

Using CMake with the Android NDK is a nice way to compile Android console applications.
Download CMake and android-cmake (set it up like this). If your program is called main.c, then write the following in file CMakeLists.txt:
project(test)
cmake_minimum_required(VERSION 2.8)
add_executable(test ./main.c)
and run cmake -DCMAKE_TOOLCHAIN_FILE=$ANDTOOLCHAIN .
You will then have a Makefile for your program, you can run make to have your test executable.

In CMake, you can cross build using toolchain files.
From google developers:
cmake \
    -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
    -DANDROID_ABI=$ABI \
    -DANDROID_PLATFORM=android-$MINSDKVERSION \
    $OTHER_ARGS
CMake has its own built-in NDK support. Before CMake 3.21, this workflow is not supported by Android and is often broken with new NDK releases. Starting from CMake 3.21, the implementations are merged.
Starting from cmake 3.21 you can:
mkdir build
cd build
cmake ..
-DCMAKE_SYSTEM_NAME=Android
-DCMAKE_SYSTEM_VERSION=23 # API level. optional, recommanded
-DCMAKE_ANDROID_NDK=path/to/ndk
-DCMAKE_ANDROID_ARCH=arm # optional, recommanded
-DCMAKE_ANDROID_ARCH_ABI=armeabi # optional, recommanded
Note: in the command above, line endings (<line feed>) are not escaped, please don't copy-paste this command directly in your shell
See Cross Compiling for Android with the NDK for more information about variables, possible values, and determenation algorithms.

Try if if the agcc wrapper can help you as referenced in the Android-tricks blog. According to the blog post you want to use the bionic library, but the one already installed on the phone, not some separately compiled version.