How to compile GCC for android? - android

Is there any way to compile GCC for android? Basically, have the GCC compiler accessible in an android terminal emulator and able to compile a binary that will run on android from a C or C++ source file.
My intention is to use this and eventually install make.

The Android NDK already includes the complete GNU toolchain which runs on your computer. You should be able to use it to compile native versions of whatever program you want.
In the NDK, see docs/STANDALONE-TOOLCHAIN.html for setting up the cross-compiler. You probably want to follow the steps for "Invoking the compiler (the easy way)" to set up a copy of the toolchain which you should be able to use with configure scripts commonly included with GNU applications (like gcc).
This really is a non-trivial task and I recommend you read the docs very carefully. It also contains various values for CFLAGS, LDFLAGS etc. that you will need to customize and use when configuring and compiling your programs.
As for compiling gcc, make, etc., themselves, it's probably not necessary or desirable to do so. gcc, for instance, is going to be huge and you may not have enough storage on the phone to install it. If your ultimate intention is to compile some program to run natively on the Android device, then I would recommend you just use the NDK and point the app's configure script at it.

Related

How do I execute a Fortran based program in Android

I have coded a program in Fortran an works perfectly in Windows, my question is if there is any way I can use it in Android.
I don't have the reputation to just make a comment, but I will answer the concern you raise of "not wanting to install compilers" to build fortran programs for android. On pretty much any operating system there are no default compilers for any language, so you have to install compilers (luckily for fortran on windows you even have a lot of options). For Android, right now, you have only one choice. That is to build your own custom version of the NDK gcc cross toolchain and force it to build gfortran and libgfortran. As of right now, gcc has been deprecated in the toolchain. Soon that won't even be an option. I have recently built the previous version of the NDK with gfortran using the following link:
https://github.com/buffer51/android-gfortran
The other problem you're going to run into is that depending on what kind of application you have on windows (command line, gui, webapp, etc.), you're not going to be able to run it on a typical android tablet or phone because there is no command line interface by default (you'll probably have to root the device to get one). The easiest way to develop a usable android app is to write a Java app (using the SDK), and then use JNI to interface with a fortran "library". Unfortunately, there is no straightforward way to compile and use your program on Android, and soon even the complicated ways (building a custom compiler) will get even more complicated.

cmake vs waf: mainly for c++ windows/linux and android

After searching a lot and reading a lot of information, I cannot decide which tool I should use for compiling my code. My codebase is mainly c++. I use primarily linux as my development machine.
Based on opinions I read before, my final candidates are waf and cmake, but I cannot decide myself which one should be more appropiate.
My primary requirements are:
Must be able to compile software in windows/linux and android.
Must be ready to run tests.
Must be able to play nicely with other libraries that must be compiled with another build system but most likely will have to be compiled from source.
Must be able to add custom steps, like for example, generating some data from some files (mainly graphics) before compiling, all integrated in the build system.
Some strong preferences are:
Being ready to support MAC compilation.
Being able to cross-compile from linux as many platforms as I can (maybe windows/linux/android but cannot MAC?)
Being able to add support for iOS compilation if the need arises.
Would be nice if the invocation interface was similar to that of autotools, since it is the one many people know and it is well documented.
Some questions:
If I have some rare requirement, which build system would be more ready to be extended?
Are both currently well maintained? (I wonder about waf mainly).
Community: if I find a problem, both communities are big enough to support me, in your experience?
For now my feeling is that I favour waf a bit as a tool, but cmake seems to have been quite successful for whatever reason.
Don't know much about waf, but CMake fits your requirements pretty well. I do know waf is written in Python, my personal favourite programming language ATM.
My primary requirements are:
Must be able to compile software in windows/linux and android.
CMake does Windows and Linux very well but so does any other build system worth its salt.
Someone wrote some Android scripts for CMake. Can't find anything similar for waf (my Google-fu turns up nothing.)
Must be ready to run tests.
CMake has a sibling testing framework.
Must be able to play nicely with other libraries that must be compiled with another build system but most likely will have to be compiled from source.
CMake has good integration with pkg-config, and can link against arbitrary shared libraries.
Must be able to add custom steps, like for example, generating some data from some files (mainly graphics) before compiling, all integrated in the build system.
CMake can generate custom rules.
Some strong preferences are:
Being ready to support MAC compilation.
CMake supports Mac quite well. It will even make you an Xcode project if you want, but it can also do command line builds.
Being able to cross-compile from linux as many platforms as I can (maybe windows/linux/android but cannot MAC?)
Cross-compiling is supported in CMake. CMake will not be the primary source of pain with cross-compiling - literally everything else will.
Especially with regards to cross-compiling for Mac. It's possible, but not worth it to cross-compile for that platform, considering you need access to a Mac anyways to get the libraries and header files, you need to patch GCC and clang and LLVM, etc. The only sound reason I've heard for going through this much pain is running an automated build server. Anyways, if you get a working Linux -> Mac toolchain, you should be able to cross-compile with CMake as if it were any other Unix platform.
Being able to add support for iOS compilation if the need arises.
iOS cross-compilation can be done, but you need a Mac.
Would be nice if the invocation interface was similar to that of autotools, since it is the one many people know and it is well documented.
Write a configure script that just calls CMake (cmake .). Then your users can do a ./configure && make && make install on platforms where that makes sense. There's also CPack which lets you generate DEB, RPM, NSIS (Windows) and DMG (Mac) installers/packages.
Some questions:
If I have some rare requirement, which build system would be more ready to be extended?
CMake is very extensible. It can be extended to support new languages and target platforms. (Given that waf is written in Python, it's going to be pretty hackable too.)
Are both currently well maintained? (I wonder about waf mainly).
CMake is mature and well-maintained.
Community: if I find a problem, both communities are big enough to support me, in your experience?
The community and extensions available are what keeps me coming back to CMake, from things like bakefile, honestly.
WAF
is pure Python
becomes part of your project, i.e. no external dependency
supports many build tools
can be used to do all kind of automations, not just building
It works perfectly for Linux, Mac or Windows.
On Android, gradle is the chosen build tool of Google. To use that is
wise, because it is set up to work by Google. You can call waf from
gradle and vice-versa, though.
If you want to learn all the low level Android
SDK tools, you could also use
WAF directly.
The SDK has
javac for Android Runtime (formerly Dalvik), Android\'s JVM, and produces a .class file
jar can also be used for Android
d8 (formerly dx) produces .dex files, with Dalvik executable code
aapt2 can then produce the .apk
javac and jar are known to WAF. For dx and aapt2 you would need
to create your own tasks, which is very
easy.
You would best make a WAF tool and
share it. Tools are either part of WAF or there is
waftools.
There are also these Steinwurf
tools.
If you make Android native code using
NDK:
you use CLANG, which is known to WAF
Further on you mentioned requirements:
WAF has waf_unit_test
WAF can do gnu_cross compilation. The Gnu toolchain knowns many
targets. But for Android you would need to set things up yourself
using the SDK or NDK. For NDK you could use the Gnu toolchain.
You would do waf configure, waf build instead of configure,
make, but you could wrap a Configure or Makefile around waf to
have the same commands.
WAF is very easily extendible with Python
WAF is now on gitlab and
constantly worked on.
The community is surely smaller than for CMake. But it is Python.
You can look into it and find out for yourself. You can also
contribute and become part of the community.

Alternative language or toolchain for creating Android programs

Is there some sort of alternative toolchain or language for Android, which can generate standalone APK files?
Ideally it should not depend on the huge and ever-changing, ever-upgraded official Android SDK.
As a parable, I am looking for a rough equivalent to how PowerBASIC and Mingw targets plain Windows just fine, despite Microsoft releasing new Visual Studios all the time.
Bonus points if this language or toolchain itself is an Android program...
As you may or may not be aware, the Android toolchain is based on a few simple ideas:
Your code is compiled using the plain old java compiler, and linked against the Android stubs (android.jar) for linkage against the system library.
After being compiled, the code is converted to dex format. You can actually run this yourself, just do a dx --help. The job of the dx tool is to take Java class files and convert them to dex code, a pretty straightforward compilation which involves going from a stack based to register based vm, and a few other changes.
After having this in place, an apk is built using a set of apk tools. It used to be apkbuilder, but this has since been deprecated. You can actually run this yourself as well. All an APK is is simply a collection of the manifest, resources, and a single file for all the code in dex form. (I.e., many .class files compile to a single .dex which is quite a bit smaller because of a wrapped web of pointers).
So the Android toolchain isn't really all that complex. The custom build process is handled by ant build rules, which are defined in an SDK wide build.xml, which you can find in the platform-tools/ directory (iirc). However, to generate new baseline projects using this custom build environment you simply use the android update project command.
While I'm not sure if this is the response you'd hoped for, I hope it will disambiguate the build process. It's not really all that complex of a toolchain, the majority of it is off the shelf Java, and not Android specific (all that makes it Android specific is library specific stubs for dynamically linked system code). Beyond this, once you have a set of classes, you need only run a few commands to make an executable APK which Android unpacks. I would suspect that any tool targeting the JVM (and capable of linking with the Android specific dynamically linked API) could perform a similar process of producing class files and using this toolchain to compile the rest of the way, though obviously the automated ant build process makes it much simpler.
EDIT:
After some more digging, I found this relevant android-developers thread. An unsettling quote:
At this time we simply don't have the resources to support people who
want to use their own build system, but we really wish we could. In
many ways we try to make it easy on other tools vendor by clearly
separating logic to eclipse or ant specific code (hence the multitude
of jar files everywhere in the tools and in ADT), but this is not one
of them.
However, you may also find this link helpful.
Terminal-IDE and AIDE are pretty much what I was looking for. Both runs on Android.

Building against GLIBC for an NDK library

I am interested in building an open source project and it requires the GNU libraries GLIBC and GLIBM. If I were to cross-compile this under Linux (I am using Ubuntu 11.10 as the host) for a shared (.so), or even a static (.a) object, with the ARMv7-a neon architecture, using API-9, as a library to call with Java's JNI, to ultimately compile as an APK for distribution, what steps would one undertake to achieve this outcome?
Given I have tried the Google NDK toolchain (setting $PATH and $CC the hard and easy way according to the documentation), a variety of custom toolchains, the Code Sourcery toolchain and a toolchain suggested on the XDA forum using crosstool-ng, is it possible to achieve a shared object file that can be called from JNI and has access to the full GLIBC library on a non-rooted Android device?
I have searched for an answer to this and the closest I have come is to build GLIBC and GLIBM locally and copy the relevant object (.o) files and link manually using the NDK's arm-linux-androideabi-ld. The libc.so.6 file from Crosstool-ng and CodeSourcery will not work as the relocations fail (giving error unknown reloc type 19) when calling the library using Java's System.LoadLibarary(). My knowledge of relocations is not the best but from what I have read this would require changes to the /linux/elf.h header file, but I am not sure exactly where to go from there.
I believe from what I have read that it may be possible to make a static executable that has all dependencies resolved when linked but then it would not be possible to package this as an APK file as far as I'm aware.
Surely I can't be the first to want to compile C code against something other than Bionic for the Android platform? There are so many C projects that could be ported to Android and apparently GLIBC has been available on iPhone for quite a while.
Any low level C library has very tight ties with the OS itself. While Linux and Android may mostly be the same thing, they are not. Building against another C library will require said C library to be ported first.

Compiling Unix tools for android

I want to use some unix tools on my rooted android arm6 based phone. I will be using cross compiler tools provided here. If I want to compile gnu netcat, how can I set the cross compiler prefix to arm-none-linux-gnueabi- and how to enable static linking (no shared library).
I managed to cross-compile rsync for Android using Ubuntu's arm-linux-gnueabi toolchain. See this related question.
Unless you particularly need to build against a more standard libc than bionic, you can just use the ndk's toolchain, either by copying the hello-jni example and changing BUILD_SHARED_LIBRARY to BUILD_EXECUTABLE in the jni/Android.mk or using the script to generate a stand alone toolchain. You may want to use the V=1 option to the ndk-build script to see the commands it's issuing to its gcc.
Otherwise you may need to pass the prefix to the configure script or manually edit it into the Makefile for the project. This often has not gone well as many projects have make systems not really set up for cross compiling, I've had to resort to editing the configure script to set prefixes and skip tests where it tries to execute a test program.
An option that sometimes works when the build system is more complicated than the project requires is to do a configure for your host (let's hope that's linux). Then manually edit the generated Makefile to change anything needed to build for android instead. Might not be a bad idea to do a clean just in case (especially if you did a test host build). And then do the build which will pick up the arm compiler from your Makefile modifications.
Lastly, if you can be content with the original netcat by Hobbit rather than the gnu version, you hardly need to port it to android yourself as that's already been done. There's already an android version in the google tree at https://android.googlesource.com/platform/external/netcat
which may be on your device already (as 'nc'), and is definitely included in alternate ROMs such as Cyanogenmod.

Categories

Resources