Develop Reference

How to build toxcore libraries on android using cygwin?

I asked a rather difficult question for me about compiling the toxcore library for Android. I read the instructions on the official git page, but without success.
I tried to build on a virtual machine under the lubuntu shell, but unfortunately I got only the toxcore library (you also need toxencryptsave). And the library itself was not read by Qt.
Tried to build via cygwin. The results are the same, but now the .so libraries are not built in addition.
Questions:
Does the readability of the library depend on the compiler? (For example, I built it on a virtual machine under CMake, and in Qt under android under CLang)
Who did it? Can you share more detailed instructions for collecting libraries for CLang
Thank you all in advance. If you really help, I will kiss everyone on the forehead

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

Crosscompiling a large C++ project for ARM/Android - issues and considerations

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.

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.

Building .so libraries on windows for use on android

I am building C libraries that will be used by an android app(through either JNI or the NDK, I've never used the NDK though) and I am wondering what IDE/development environment is best to use? I've basically only used Visual Studio for native development and I'm not sure how to adapt to building .so libraries for use on android.
Thanks
EDIT: Update -- I want to avoid makefiles if possible (never used them) and rather use a complete IDE such as the case with visual stuido to compile

Generally, cygwin (i.e. command line) is used for building Android native code. But you can also try to use Eclipse for this purpose. It doesn't help very much but it highlights syntax and you don't have to switch to other apps to write code and build your app. You can read more about using Eclipse for C/C++ Android development here.

I would strongly recommend that you use the NDK's compiler.
Normally this is done by writing an Android.mk in accordance with the instructions for the NDK. It is not complicated. The easiest thing to do is to grab the hello-jni sample app and just make the necessary changes, for example substituting your source files into its android.mk.
You can stay in visual studio if you like that as an editing environment, simply using the ability to bind an external command to a keystroke to launch the ndk build script. Ages ago I had figured out how to reformat GCC error messages with sed into something that VS could parse to make them click-able, though I soon moved development of that project under linux.

I think a lot of people use Eclipse as their IDE for Android development. I use it and its pretty good. You shouldn't have any problems if you're used to VS.

The Android SDK comes with a plugin, the Android Development Tools (ADT), to develop applications for Android inside the Eclipse IDE, which is same kind of beast as Visual Studio. And within that IDE, it is possible to use JavaCPP (disclaimer: I am the author) to have it compile all the native C/C++ stuff we need through the Android NDK, but without needing Makefiles and such. More details here:
http://code.google.com/p/javacpp/#Instructions_for_Android