I have not found much helpful information through my Web-searching and email-asking. I would like to compile Haxe on an Android device using a fully-functional Ocaml Android port. Binaries are available for Linux, Windows, and Macintosh, but all are x86. I have heard that Ocaml can cross-compile to ARM or something, but Android support was dead. Is that true? What has changed since 2012? I have Terminal IDE installed, so in theory it is possible for me to run command-line apps on my device. This should be sufficient for Haxe, but as an Ocaml program I assume that such would necessitate Ocaml's Android native code generator working flawlessly. Please fill me in on this, as I cannot find conclusive information in other channels.
Related
Im create simple game, remake my old ZX-Spectrum game "m2k"
Love2D is simple engine using LUA.
What i need:
Compile Love2D -> exe files, linux binary, android apk.
Goal is pack Win32, Linux64 bit and android apk WITHOUT possiblity of just unpacking .love file and WITHOUT manual installing love2d engine.
https://pp.userapi.com/c637425/v637425257/4a8a8/QCv9Q5dz_b4.jpg
I cannot found anything useful about it. I found LoveExporter 0.2 by shake but this utilite fails compiling normal binary. It fails with error.
All manuals tell me just create .love file and send it to all. No way.
It's no good for me.
Maybe i can run this utilite. I fails with 0.2 version maybe 0.1 works
http://snake174.github.io/html/programs/love_exporter.html
Partially it works, but it requires Microsoft Windows, and android support is broken. Developer not create new versions about a year +.
I don't want to pay for windows, reboot to windows or another using unsafe OS, and requires Native full work analog.
etc
Compile Love2D -> exe files, linux binary, android apk.
The wiki already has a guide for creating executables for Windows, Linux, Mac and Android. Unless I'm misunderstanding your request, you need this.
(Perhaps a border-line question on S.O since I am not showing any source code!)
I want to be able to cross-compile (using the latest GCC trunk, i.e. 4.9) a hello world program in C, compiled on Linux/Debian/Sid/x86-64 for Android (4.4.2 on a rooted Nexus 7), and to be executed in an Android terminal emulator. My goal is to learn how to configure the entire cross-tool chain, probably GCC, binutils, and MUSL libc. So I specifically do not want to use any SDK or NDK for Android!
I guess that my Android is an arm-linux-gnueabi GCC 4.9 primary target platform for GCC & binutils. Is this correct?
Then once I compiled my (statically linked with MUSL libc) hello world, how should I transfer it on the tablet? (MTP probably).
PS. I am quite familiar with Linux (and GCC, to which I contribute, and binutils) but I am a complete Android newbie.
PPS: The real motivation is that I want to compile a plugin for a GCC cross-compiler, preparing a talk about GCC plugins
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'm working on a software designed to compile and run on Linux. I was recently asked to cross-compile it for Android using the NDK, which was surprisingly straightforward.
To do this quickly, we just compiled the source, without writing any JNI wrapper. I copied the resulting binaries with adb push to an emulator (rooted) and ran it from the adb shell. Everything worked fine.
Now my question is: How can I embed those binaries somehow in an android application and run them (they act like services and must run in the background) ?
I'd like to avoid changing the existing code to support a JNI interface, but writting a small JNI/C code that just exec the other binaries is fine.
Bonus question: once embedded, is there a way to know the path of the installed binaries ?
http://www.ibm.com/developerworks/opensource/tutorials/os-androidndk/index.html
i found the nice tutorial in IBM developersworks about Android NDK
I can cross-compile any C/C++ application, statically link it Linux libraries and run it on Android. What was the need of an Android-ndk then? Android-ndk limits us to bionic which has a small subset of gnu libc. Isn't it a better idea to straightaway cross-compile applications and run them through Android shell? Is there any limitation to cross-compiling that I can't see? This URL : Can Linux apps be run in Android? answers my question to some extent but eventually leaves me confused and without clarity.
I think this is enough for Android-NDK
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
The NDK provides:
A set of tools and build files used to generate native code libraries
from C and C++ sources
A way to embed the corresponding native libraries into an application
package file (.apk) that can be deployed on Android devices
A set of native system headers and libraries that will be supported
in all future versions of the Android platform, starting from Android
1.5. Applications that use native activities must be run on Android 2.3 or later.
This thing you can not find in other cross-compilation with arm toolchain..
As mentioned in the link http://developer.android.com/sdk/ndk/index.html NDK is a companion for App development folk to create performance sensitive native code. NDK exposes some of the native implementation of Android which could not be found in the general Linux environments. Some of them include the Android/Bitmap, Android/nativeWindow etc. Using these Android natives applcation can speed up CPU intensive processes like some compression or decompression of images.
Even though the externally cross-compiled executables may run in the Android there no guarantee that versions of the standard library implementaions are the same. NDK provides a easier and Android compatible toolchain and other resources, using which is much easier to application developers than having to find a compatible cross-compiler for their usecase.