Codesourcery with gfortran support? - android

Has anyone successfully added gfortran to a Codesourcery lite for ARM build? If not how do you properly work around this with f2c to compile fortran code with codesourcery?

The CodeSourcery tools come with a file that shows the commands used to build them. It's not exactly a build script -- you can really only use it for reference -- but you should be able to rebuild the compiler with Fortran support if you try hard enough.
Obviously, CodeSourcery won't have tested Fortran much, so if it is broken somehow, you're on your own.
If you're targeting ARMv7-A, you might find the Linaro compilers more effective:
http://releases.linaro.org/12.02/components/toolchain/binaries/
Linaro also have specific Android tools, of course.

Related

Installing NDK (arm-linux-androideabi-gcc) on Android (Remix OS)

I'm trying to install some python packages (pillow) for QPython on Remix however I get the error that arm-linux-androideabi-gcc does not exist.
I googled and I think I need NDK, however looking at the website (https://developer.android.com/ndk/downloads/index.html) I couldn't find a way to do this on android.
Any help is much appreciated, thank you!
Installing the NDK on Android? As in running the NDK compilers on an Android device? We don't support Android as a host OS for the NDK.
Check out AIDE android ide from the Google playstore
Despite Dan's answer, which I respect. It's not entirely accurate. The Android ndk build system doesn't allow for for host to be set to the $TARGET_ARCH, but building it manually in much the same way you would for any custom toolchain is entirely possible.
I should note that I have only done this for gcc, and have not attempted to do so with clang.
From Googles ndk toolchain repo just take the essentials needed, gcc, binutils, gmp, mpfr, etc and set your host and target to the ndk toolchain gcc. Use the ndk sysroot as build-sysroot, and then just add your compiler flags and with a little fiddling you should get it.
Id be happy to post more, it's been a project of mine to build Android on Android, also i highly recommend adding static versions of the ndk libs, as the android system doesn't have a c++ lib, and a few others. You may have to build some manually using aosp build system
I built it with stage-one flags so that the binaries would be static, as you never know when android might remove a lib that your toolchain depends on.
I encourage you to try, as an added benefit you will then he able to build many useful android native binaries that usually aren't available without editing the aosp source. Also having the ability to build binaries on the fly is very useful

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.

Profiling android-ndk plain C/C++ executable

What is the best way to profile plain C/C++ android executables on a rooted android device?
android-ndk-profiler seems to support only ndk libraries linked to Java.
Any suggestions?
Thanks
I was faced with the same question recently. After looking into several alternatives I decided the best option (the one I made to work, at any rate) was to build Valgrind for Android.
This page describes how to build Valgrind for Android. See also my GitHub project for a slightly different build procedure, usage notes and prebuilt Android ARMv7 binaries.
Android NDK profiler work by GCC compiler trick so should work independent
of JNI
This link has the details
http://code.google.com/p/android-ndk-profiler/wiki/HowItWorks
As long as you can insert the startup and cleanup code into your C/C++ code it should work
You can find all the information you will need here
http://code.google.com/p/android-ndk-profiler/

How can I enable c++0x in a vs-android build

I am using vs-android (http://code.google.com/p/vs-android) to compile c++ projects for the android platform with the ndk.
It all works well except for when compiling code that uses features from the c++0x/c++11 standard such as std::function, nullptr... I'm assuming, or at least hoping, that I can fix that by adding the compiler option -std=c++0x.
I tried adding that in "Additional options" under "Command line" and some errors seemed to go away but not all of them. Including causes problems, types.h complains about uint64_t not existing and many other similar problems.
Does anyone know how to fix this? There is nothing wrong with the code as it compiles perfectly with msvc10 targeting a windows platform. I am using visual studio 2010.
Thanks
vs-android now supports gcc 4.6 which has pretty good c++11 support, and if using -std=gnu++0x instead of -std=c++0x the uint64_t type is defined.
Even if vs-android is using Visual Studio as the IDE, it is still using gcc 4.4.3 as the compiler (which is released 2.5 years ago). For example, according to http://gcc.gnu.org/projects/cxx0x.html, nullptr is supported only starting from gcc 4.6, so you can't use it.
I don't know about the uint64_t problem. But you'd better stick with C++03 (or even C) for NDK.

Is it possible to compile LLVM libraries to android/ARM

I'm fascinated by the Pure algebraic/functional language. The Pure interpreter uses the LLVM JIT compiler as its backend.
I would like to compile Pure so that it runs on Android(ARM). Pure has a dependency on the LLVM JIT. So I need to compile LLVM source for Pure to run.
Is it possible to compile LLVM source for Android (ARM) devices? There really seems to be no information about this on the web. Maybe my search terms are wrong. Searching for Android LLVM does not bring up many good hits either.
It now seems possible, the NDK now supports Clang which uses LLVM. So maybe it can be made to work with any LLVM language. AOSP should give us some insight on how they added Clang support. See the latest Android NDK for details on Clang support.
Android NDK, Revision 8c (November 2012)
Important changes:
Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows:
For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting to Application.mk.
For standalone builds, add --llvm-version=3.1 to make-standalone-toolchain.sh and replace CC and CXX in your makefile with /bin/clang and /bin/clang++. See STANDALONE-TOOLCHAIN.html for details.
Note: This feature is experimental. Please try it and report any issues.
While you can surely compile LLVM on ARM (it's pretty trivial - just ordinary configure + make system), you're still out of luck: JIT on ARM is still work-in-progress, so I'd not expect it working for everything non-trivial.
It seems like the Android NDK would help in this, as one of its usages per its FAQ page is to reuse C/C++ code.
I think we shuld see on mix of LLVM + Android NDK (C++).
I'm thinking about SmallTalk-like dymanic object system (*), and LLVM usage is very interesting for lazy dynamic compilation on Android devices.
First try you shuld build something like tiny Buildroot/OpenWrt Linux system (or build you own using CLFS or my scripts: https://github.com/ponyatov/L/tree/clock )
for ARM device like Raspberry Pi (it's my case for testing). If you got good results on this variant, later you can migrate to Android device itself. I think you'll need some C++/NDK glue code to adopt LLVM/Pure core vs Android runtime and GUI. (**)
(*) but with my own language syntax, lisp-like functional abilities to mutate all system internals, parser/compiler integrated framework, and maybe some basics of symbolic computer algebra
(**) is Android Pi alive ?
As far as I know you can't build LLVM for ARM devices just yet.

Categories

Resources