Threads for gtrs

  1. 5

    @andrewrk Would it be a lot of work for you to add an android target to your awesome Zig cross-compilation machinery? Ideally, without requiring me to install the whole Android NDK? In my spare time, I’m working on a lean “toolchain” enabling building .apk files without having to install Android SDK nor NDK. Currently, I have working minimal prototypes of:

    Now I need something that could build JNI .so files for Android, that I could embed in .apk files. Currently I’m generally targeting Nim, but it requires installing Android NDK, and I haven’t tested yet if the Android target is still working in Nim. If I could build Android .so JNI files with Zig, it could sway me its way… at least for this stage of the effort… and, once I get it to work, I would be more than happy to do a writeup for the Zig community on how to build Android APKs this way, kinda in return!… *nudge, nudge, wink, wink* also much tempting, no? ;P Also, maybe I could then make Nim use the Zig’s embedded C compiler instead of the Nim’s default GCC/MinGW, for some kind of an unholy marriage of Nim+Zig?

    1. 3

      I’ll encourage you to check out DockCross. I was able to build Nim binaries for the android-arm64 target with minimal effort. Of course, it only has the r16 version of the NDK but maybe that’s a good thing? I don’t have any Android experience per se but maybe this helps.

      1. 2

        Thanks! DockCross may be interesting, though rather as an intermediate step, as I’d prefer to avoid having to install docker as well. I’m aiming to minimize the size and dependencies. Did you manage to build a .so library usable in an .apk? That’s what I’m interested in for JNI.

      2. 2

        This is definitely something I want to explore. I don’t have much experience with Android development so it would be a big time investment personally to look into this, but I would be happy to provide guidance to someone who wants to go down this path. If ability to cross compile for Android out-of-the-box added less than ~10MiB to the total download size of a given tarball on, I think that would definitely be worth it.

        As for Nim they should just do exactly what Zig does and use clang/llvm libraries instead of depending on a system C compiler installation. I don’t see any advantages to the way they have it set up.

        1. 1

          Hm; so, what would be the first steps I’d need to take, if I wanted to try exploring this path? Assuming I’m on Windows and have the Android NDK (or sources?) downloaded? I don’t have much experience with Android dev either, but willing to try and see how far I can get with some initial low hanging fruit(s).

          1. 1

            The first step would be determining what is the ABI of those .so files. What functions do you need to export? What types do you need to know about? What are the files in the NDK and what are they used for?

            What ABIs does native Android code have available to the system? Are they defined by the NDK? Are they stable? How often do they change?

            In summary, the first step is figuring out, in low level details, how the whole thing works.

            1. 1

              As to the ABI (and syscalls, etc.), I’d imagine that’s probably encoded in some patchset they maintain over Clang, no? Would you mean having to reimplement the whole diff, either by rev. eng., or by finding the sources of the actual patchset online and just grabbing them? Plus understanding them. I’ll try to look around if the patchset is somewhere to be found, hopefully it could shed some light.

              edit: FYI & FTR, this seems to be a potentially good docs starting point for further reading and exploration. Though still a bit too high-level. A bit more is here. Anyway, the sources seem to be available. That said, given that I don’t have enough knowledge about clang, I don’t currently see clearly any low hanging fruits for me here, unfortunately. (Hmm, unless maybe cloning this and clang and running a diff? Hmm, but for this I’d need a Linux box…) So, for the time being, I think I’ll back off from this avenue. But I’ll keep it in mind, maybe it’ll grow on me enough to reevaluate it one day. Thanks for the heads up!

              edit 2: As of Android 7.0: Clang has been updated to 3.8svn (r243773, build 2481030). Note that this is now a nearly pure upstream clang.

              edit 3: There’s some more info how to retrieve toolchain sources; but it seems to use some repo tool, and I’m currently not able to understand how to dig up the actual eventual git repo & commits :( from it, I believe the clang sources are at:; IIUC the branch master upstream-master might be “vanillla clang”, and dev or master might be with patches applied. Not confirmed yet.