I've run into a very serious (IMO) problem. I am using the native cross platform tools in visual studio 2015.
Since several implementations of the standard library were downloaded by visual studio
C:\ProgramData\Microsoft\AndroidNDK\android-ndk-r10e\sources\cxx-stl\
I was surprised when I started finding stl classes that were not compiling.
I wrote off std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> not being available as a quirk of gnu-libstdc++.
I tried to set the stl to others to see if they were better. This was done in the visual studio project properties window.
No combination of toolset or STL made std::wstring_convert<std::codecvt_utf8_utf16<wchar_t>> available.
I moved on, saying "If I have to implement that one function myself it's not the end of the world."
However shortly afterward I tried to use to_wstring. Again the function was not recognized even though wstring was.
This was a step too far so I checked to see if gnu-libstdc++ had in fact implemented anything at all. In fact they had, see 21.5 of the standard is Y.
I was very confused now. I did some googling and found nothing more substantial than "set it to c++ 11."
Unless Visual Studio isn't doing anything with the following setting I assume GCC is being called correctly.
Eventually I opened up basic_string.h in visual studio to make sure that the function was actually there.
It was, line 3000:
inline wstring
to_wstring(int __val)
{ return __gnu_cxx::__to_xstring<wstring>(&std::vswprintf, 4 * sizeof(int), L"%d", __val); }
Then I saw by the shading that it was being omitted by the preprocessor. Behold line 2847:
#if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \
&& !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF))
The problem was not __cplusplus nor _GLIBCXX_HAVE_BROKEN_VSWPRINTF. _GLIBCXX_USE_C99 was not defined.
Searching for this problem yielded a couple of stack overflow questions.
Most of the comments seemed to think the problem would be fixed with a new release of GCC. For instance GCC 4.4.5. However since visual studio downloaded 4.9... I don't think this is merely a problem with versions.
I followed the link there to a three year old bug report which contained the statement:
It's not possible to fix in GCC without extraordinary effort for a
single target, which is not going to happen. If a given target wants
to support C++11 features then it needs to provide the necessary C99
features. This is not a GCC issue.
Well, in visual studio I had set the C standard to C99, for the record C11 didn't make any difference.
I am really not sure how to proceed from here. It seems to me that somehow Visual Studio is not communicating to GCC what is or is not available. That is just a theory though.
I am opposed to trying to manually change a distribution on the stl. That defeats the purpose of a stl. At the same time this project I am undertaking may well be impossible without the standard library (given the time constraints). I am afraid to continue lest I find more critical functionality hidden due to lack of C library functions.
I have this insane hope that there is something I could change in visual studio, some setting or command line override that would fix this.
P.S. I have looked into developing the android part in eclipse or android studio. The NDK documentation mentions eclipse often, but the android SDK has scary messages about the ADT no longer being supported. On top of that I had issues out of the box debugging the native code (but those are beyond the scope). The android studio build system (gradle) doesn't seem friendly to custom folder structures in the least. All of our source is in TFS and I can't change that at this point.
This is known problem of Google's Android NDK - C++ Standard Library is broken there, unless you're using just small subset of C++ functionality. Macro _GLIBCXX_USE_C99 is defined (or not defined) in $NDK/sources/cxx-stl/gnu-libstdc++/4.9/libs/$ABI/include/bits/c++config.h at the moment when GNU libstdc++ is building (i.e. on Google's side, when they build NDK). Unfortunately, it's built on top of very limited libc (Google's Bionic), so GNU libstdc++ configuration scripts detect it and disable some parts (in particular, std::to_wstring), depending on that absent functionality in libc.
This is one of the main reason why I've started CrystaX NDK - alternative native development kit for Android. In CrystaX NDK, we pay special attention to completeness of libc, libstdc++, and conformance to standards in general. CrystaX NDK works as a drop-in replacement for Google's Android NDK, so most likely it will just work with Visual Studio too.
Related
I want to make an interface for a C++ complicated algorithm on a tablet environment, the idea of a server running the C++ code isn't applicable.
Can I embed my C++ algorithm in NDK application (for android, can I do the same for iOS?) and make the interface with Android SDK, and then use the NDK app (maybe as a function) in my SDK android app?? is this scenario possible and how hard it's?
I'd prefer the most a solution involving cordova and hybrid approaches.
If there is a simpler approach I'd appreciate any idea.
You probably want to port some code to Android. I do not know if you code has been ever built under Android.
Anyway, first of all you have to locate and manage to build the hello-jni example in the Android NDK. I have it in android-ndk-r9d/samples/hello-jni. After that, you may start to add functions to that project. Forwarding data between Java and C++ is... well... error-prone.
Android comes with two build systems, the old one is ant-based, the new one is gradle. In addition, some guys manage to use 3rd-party build systems for Android.
If your project has never been built under Android, you will have to port it. If it has Windows/Linux/Mac builds, start from a Linux or a Mac one (in the latter case please note that "darwin" contains "win", this may cause bugs in your build script.) You will likely have to borrow some standard functions from where you can find them. In addition, a while ago Android did not support std::string at all...
If your project has been built under Android, you will have to manage to build it yourself and then use the binaries. Alternatively, you might prefer to just use the existing binaries (this will require less effort) and just not care about bugs.
One more possible approach is to find the project that both uses your preferred build system and has an Android build, build that project for Android and remove the contents, thus obtaining an empty project that is built with your build system of choice. I did no do this and I suppose it will not be as easy as it sounds now. (But you will have a chance to become an expert in that build system.) UPD This section applies mostly to projects that come with a 3rd-party build system. Usually such exotic build systems have some specific features, and one needs these features to build successfully. The general rule is that beyond some level of complexity all working systems are modifications of other working systems (and are never created from scratch). (Example: programmers add functionality gradually and testing is done after each addition; they just cannot write all and then test all.) So in the case of a 3rd-party build system it may be reasonable to take some working project using that 3rd-party build system, get the build system working and replace the project source.
In general what you want is possible for both Android and iOS, but there is no general-case solution.
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.
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.
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.
Since Objective-C exists and is supported even in MinGW, by passing -x objective-c, is there a hack to achieve this with Android SDK? I've did a rudimentary test on a colleague's machine where it appears that language objective-cis not supported.
I am not interested in getting UIKit or AppKit, or even Foundation, to work; I've written most of an OpenGLES game in Objective-C, and successfully ported it to Mac OS X and Windows; I am fairly certain I could easily port it to GNU/Linux once I get time to figure out enough of GNUStep (and even without it, I could create the classes to get the game running).
I'm just interested in the base language and basic runtime (including properties, if possible); even NSObject can be easily written to the extent I need it.
In the meantime, I've managed to compile some Objective-C code, and have written a guide for this:
Developing Objective-C apps for Android using Mac OS X
There are more details in my answer below.
The Apportable platform includes a Clang compiler integration with the Android NDK. It also includes a bunch of other useful features if you want to go beyond basic Objective-C language and runtime support.
You probably have to recompile the ndk gcc's sources with that option enabled. At the extreme you might have to find the code for that option upstream and add it to the ndk gcc's sources.
Porting runtime libraries to work on top of bionic instead of glibc may be more interesting.
Note that android doesn't really handle pure-native binaries very well, you will need to either be called as a jni library from a java wrapper application which you will have to call back up through for audio or forked and exec'd off of one (not recommended, and leaving you with device-dependent hacks for audio).
There is this Google Code project: http://code.google.com/p/android-gcc-objc2-0/ however I have not tested it yet.
Also, I have inquired on the Cocotron mailing list whether or not this compiler is usable with Cocotron's Foundation and CoreFoundation; one person responded that it is not, and that he has worked on the problem: http://groups.google.com/group/cocotron-dev/browse_thread/thread/448355f2a6c9c28e#
In the meantime, I've managed to compile some Objective-C code, and have written a guide for this:
* Developing Objective-C apps for Android using Mac OS X
Clang is included in NDK nowadays if that's all you need.