I wrote a library in latest Linux distribution, which depends on glibc and sockets. I hear that glibc is not supported in Android. Is there a way that I rebuild my code without much modification for Android and let it run? If yes, I will use JNI to call the code.
No, that's not possible. Android runs with bionic, and doesn't have glibc.
However you can try to build your code with NDK and fix the problems on the way to build it.
If you don't use anything glibc specific, it should be fairly easy.
It depends on what you mean by "uses glibc". If it uses non-standard extensions that only glibc implements, then you'll have some trouble. But Android's libc (called "bionic") supports most of POSIX, so if you aren't doing anything too unusual, it should work. The best way to find out is to try to build your library with the NDK and see what happens.
Related
As far as I know one can can write apps on Android and iOS in C/C++, instead of Java and Objective-C.
Since both C and C++ rely upon their Standard Libraries, where and how the C/C++ Standard Library is implemented in such OSes? Is it part of something bigger like e.g. the Android NDK? If it isn't, can I use a different implementation if needed?
There are several concepts at play here, I'm going to try to keep it brief. Android uses Bionic as its C library. It also lists different C++ libraries, however, they recommend you stick with libc++ (Clang) since they have stopped supporting libstdc++ (what they call gnustl) and STLPort is ancient. Now even though they call libstdc++ the system runtime, for libstdc++ in particular, the support library is called actually libsupc++. In order to have exception and RTTI support, you need to implement/build this, which doesn't seem to be the case for Android.
For Apple, it's a different story. XCode is the IDE (not the compiler!) On old versions of Mac, they shipped an ancient version of GCC. There was a transition period where they used llvm-gcc and symlinked gcc to clang. Now the latest version of XCode only supports LLVM/Clang. By default, Mac uses libc++, but you can select libstdc++ if you prefer. Keep in mind that although Clang tries to be as ABI-compatible with GCC as possible, it's probably not wise to mix libraries compiled by libc++/libstdc++.
Can you use a different C library in your toolchain? Not easily. You would need to port the C library of choice (i.e, Newlib) to the platform which is not trivial. Further, you would need to build a cross compiler toolchain that not only targets that system but also uses the new library. You will have to look into people who have already done this for you.
Now even if it was easy, there really isn't a good reason to. More often than not you only want to swap out selective parts of the library, like malloc. Android in particular can use jemalloc for example.
In our team we have a C++ project built on OpenCV and VLFeat written by a colleague who has just left.
I have been asked to cross-compile it for Nexus 4 (ARM), run it and profile it (gprof).
Hence, it is not necessary to pass through the Java wrappers and the NDK: no app is requested.
I am having big troubles with that because I am a complete novice in crosscompilation: all the guides and tutorial I find advice to use the NDK. For example, this book very nicely explain how to setup the whole system (using the NVIDIA Tegra development kit that bundles the Android SDK, NDK, Eclipse and OpenCV)
Do you think that crosscompiling such a big project with so many dependencies on arm it is a viable option? I am also concerned that, even in the case in which I will manage to cross-compile, the code won't work.
If yes, can you kindly point me to some resources which explain me how to do it (besides the OpenCV instructions, which have been not particularly useful)?
If no, I would really appreciate if somebody with more experience than me in the argument could debate the reasons why it is much better to use the NDK.
------------- EDIT ------------
For sake of completeness, I report my progresses.
I managed to cross-compile OpenCV for ARM, generating static libraries. I have also successfully crosscompiled VLFeat.
Now, it happens what I was afraid of: make throws up a huge list of undefined references. I have pasted the head of the &> output in this pastebin.
Any consideration? I am almost seriously convinced that a rough cross-compiling will never work, and it is better to re-do the entire project passing from the NDK. Obviously, I hope that somebody could contradict me.
Thanks in advance for your help, I do not know which way to turn.
You can just use NDK compilers and regular makefiles without using the NDKs build scripts. There is script that makes NDK compiler behave more like a regular GCC right here https://code.google.com/p/android-cruft/. The script was last updated 4 years ago, so it might need further facelift.
The biggest problem you might face is incompatibility in the C library or missing support for advanced C++ features. The Android is somewhat Frankenstein system, it uses linux as a kernel, but BSD like C library. Many low level utilities do not compile well for such environment. Also, a lot of C++ features depend on libg++ library which might have strong tie-ins into GNU C library.
I had a look at your pastebin. The first thing that stands out is libjpeg, or lack thereof. I don't know how your link step did not involve -ljpeg. You also need some pthread - related stuff. Note that Android supports almost all pthread APIs, including pthread_mutex_init(), but does not have libpthread; instead, all these functions are defined in libc. Maybe, other libraries are missing, too.
We're building a big app, including OpenCV, boost, libjpeg-turbo... For all this we use CMake to generate Makefiles that use the NDK.
Looking at your linking errors, it seems you're missing some libraries in your link command line. -ljpeg probably. For pthread, I'll have a look at how we handle it at work.
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 a way to port Snort to Android OS? I have already ported
libpcap to Android and I have made some simple native sniffers which worked
perfectly.To do this, I used the NDK development kit that offers you some
tools for cross compiling C programs to ARM architecture.
Is this possible to do it for Snort. I know that Snort is a big project that
contains many source files and uses many modules such as Libpcap, PCRE,
Libdnet, Barnyard2, DAQ. I am wondering if is there a way to build
this code for Android.. E.g. by statically link all this modules.. Moreover an
other potential problem may be the fact that Android uses a subset of libc
(bionic), so maybe some basic functions are not available..
Have anyone done it before? Or, can some one give me some help on how
to start?
Lack of exception handling and STL was very painful when i ported using NDK. As snort is C based, that shouldn't be the case. I guess unicode handling (as ndk doesnt support wide char functionality) can get tricky.
Has anyone used the Android NDK to port a Linux app? We have an SSL VPN solution at work which Openconnect (http://www.infradead.org/openconnect.html) works with, but there is currently no client (from Cisco or otherwise) on Android. Is using the Android NDK a feasible approach to get this to work?
Thank you in advance
The NDK is a good solution for porting C/C++ Apps. You need to do a thin java shell to pass over any input, init and exit the program.
If your C app requires STL or exceptions - there are modified versions of the NDK that support them.
The Android NDK is not for porting apps. It is for creating libraries that can be accessed from a standard Android Dalvik app via JNI.
So, if you have the source code to this project, and it results in a .so, and you can write a JNI wrapper for it, the NDK may be a solution for you. Considering the project you cite seems dependent upon scripts, I suspect that's not how it was set up for use.