Build executable as library

[sp1ritCS]

For the android backend for GTK, we'd like to have a builder application/script that is ideally capable of producing an apk file when pointing it at meson project utilizing gtk.

As android applications are somewhat special regarding initialization (fork of pre-warmed JVM), we don't need an executable but a shared library providing the application entry point.

Specifically the current initialization routine looks like the following:

• On activity start, the glue library gets loaded. The source for the glue library is part of the gtk codebase, but it only gets built via Gradle/CMake during compilation of the app^[1].
• The glue library provides a well-known symbol Java_org_gtk_android_GlueLibraryContext_runApplication, which initializes glib/gtk and starts a new thread in which main will get called.
• The glue library is linked against the user code as shared library, which provides the main symbol that gets called.

This means right now, if I want to build a gtk application for android, I need to change the meson target from executable to shared_library/shared_module. This is something I'd rather want to avoid and instead rely solely on a cross file / meson parameters.

Right now, this isn't really possible (best I could to is probably add -shared -fPIC to compiler/linker flags), so I'm looking for suggestions on how best to implement such behavior. Alternatively I'm not yet really set on any specific procedure, so if someone has a better idea than the current one feel free to tell me.

[1]: I have thought about building the glue code as an object file (.o) during the compilation of gtk and then just have CMake link that file into a shared object. But its seemingly not possible to get meson to produce object files (.o) as output?

[eli-schwartz]

This means right now, if I want to build a gtk application for android, I need to change the meson target from executable to shared_library/shared_module. This is something I'd rather want to avoid and instead rely solely on a cross file / meson parameters.

Is this a general issue such that the android platform only really makes sense to produce shared libraries like this? Are executables still expected to be named "foo" or "libfoo.so" (guessing the former)?

[1]: I have thought about building the glue code as an object file (.o) during the compilation of gtk and then just have CMake link that file into a shared object. But its seemingly not possible to get meson to produce object files (.o) as output?

Not entirely sure what you're trying to do here. Is it not possible to build the app inside meson?

If you need some common code exported to another build process, usually you'd do that by producing a static library and having the other build system pick up the static library as a dependency. So you'd use libfoobar.a, not foobar-util.c.o

[sp1ritCS]

Is this a general issue such that the android platform only really makes sense to produce shared libraries like this?

No, you can do fork + exec to launch an actual executable but that then only has limited access to interact with the operating system, so both is necessary.

I was maybe thinking about adding an android_usecase kwarg to executable, similar to the win_subsystem, which could be either set to executable or application.

Are executables still expected to be named "foo" or "libfoo.so" (guessing the former)?

It technically doesn't matter, given that you could link against "foo" using -l:foo, it would however be useful if it follows library naming conversions (or at least ended in .so), as gradle doesn't copy any non libraries from the jniLibs directory into the apk.

---

Not entirely sure what you're trying to do here. Is it not possible to build the app inside meson?

Building the app right now is a multi-stage process. Only the user-code (the one providing main) and its gtk (+ deps) subprojects get built in meson, while the glue library gets built and linked against the user code and gtk using CMake. That is, because the android gradle plugin only supports ndk-build and CMake as buildsystems and has a codebase so horrible I wouldn't even know where to start to hack in meson support.

While I could build the glue library in meson too (and move the built glue library into jniLibs), that'd mean that the build step of building it wouldn't be automated the way it is right now. What could be possible is having meson link the glue code into the not-executable executable that is the user-code (similar to what crt1.o does for the c-runtime) but the final product being a shared library instead of a executable. This would probably have to be specified via the cross file.

usually you'd do that by producing a static library and having the other build system pick up the static library as a dependency. So you'd use libfoobar.a, not foobar-util.c.o

The issue with .a was, that I could either link it normally, in which case the symbol didn't get exported, or link whole, where I had issues with duplicate symbols (from bionic I think).

[sp1ritCS]

Something additional I've noticed with meson is, that it isn't seemingly possible to a parallel setup for multiple architectures.

As android needs shared libraries for x86, x86_64, aarch64 and armv7a (mips32el, riscv64) I was planning to run meson setup --cross-file toolchain.cross --cross-file "$asset_dir/arch/$arch.cross" --cross-file "$asset_dir/android.cross" $OPTIONS "bin-$arch" ".." for all arches in parallel.

This fails with ../meson.build:406:17: ERROR: Subproject exists but has no meson.build file. if a meson instance attempts to access a subproject while another is currently downloading it.

Would you accept some sort of subprojects locking implementation or is it just not possible to configure in parallel?

[eli-schwartz]

I guess I don't mind a locking implementation. Just no one really thought about this possibility before, I guess.

For what it's worth, you can use meson subprojects download once, to download all (relevant) subprojects. It even supports -j, funnily enough. :) Then after that finishes, kick off all the parallel meson setup invocations.

That works today, with no blocker on actually implementing locking, getting it merged, and waiting for a meson release.

[sp1ritCS]

For what it's worth, you can use meson subprojects download

Oh nice, I was under the assumption that this would just download the wraps defined in subprojects/ and not recurse any deeper