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
Related
I am trying to deploy a Qt app to an Android device, though I receive the error about missing stdlib.h. I found out that this library is actually inside sub directory tr1 of includes. I modified the include<stdlib.h> to include<tr1/stdlib.h>. After this I encountered the error for locale.h. This files doesn't seem to be present anywhere in the NDK.
The app works fine if build for Desktop as the Linux GCC has all files in proper hierarchy.
Any fixes?
Finally, I resolved the issue. It was just the wrong Android NDK build I downloaded. My system architecture is x86_64 and the Android architecture is x86. The build I downloaded was that x86_64 Android. Make sure when downloading the target platform is your Android architecture.
Also, one might find several solutions recommending to create stand-alone build using make-standalone-toolchain.sh script and setting CXX home to this build and as well as set "sysroot". Please do not do it. It's not at all required. Just set the NDK path from Android option from Qt itself. That shall be enough.
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.
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/
Is there any advantage of using the NDK build system ndk-build and Android.mk to build ndk project instead of using standalone toolchain and Makefile / make.
ndk-build is just a wrapper around make. You can see that in its source:
This really is a tiny wrapper around GNU Make.
However it does handle a lot of small bits for you, so you should use it unless you have some strange setup.
If you don't already have a make file, or don't plan to build your project for other platforms (iOS, Windows, Mac, Linux...), I would recommend going for ndk-build.
Android.mk is easier to construct and maintain, especially in regard to next upgrades of Android NDK. It's hard to forsee the future, but it has been straightforward to target new Android versions, new processors with NEON, v7, or x86 and MIPS.
Definitely not. Or at laast not that I could find.
ndk-build may be easier to use on small scale applications.
But when a real-world large build system is needed - just go with your own and be sure you use the toolchain from the android-ndk folder
I'm trying to build a linux library for Android, but it seems that libtool for the android gcc toolchain doesn't include ltdl, the dynamic loader. Is there a system-related reason for this, or is it just not there?
How would I go about incorporating the ltdl from www.gnu.org/software/libtool/ into an android build?
Thanks!
Many of the standard libraries are 'missing' from the Android NDK most likely for technical reasons of which I am not aware. I do believe in the release notes for the NDK there are entries for those standard C libraries which are not currently incorporated there might be a mention in there as to why ltdl. I can only suggest to get the source and create an Android NDK project and build it that way. Although may I ask why you need the dynamic loader.. android loads libraries as required anyway (so I understand in my limited knowledge)