Android.mk build system limitations

Android.mk build system limitations

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 4346 bytes --]

Hi,

I'm maintaining a library that can be used in both Android and
GNU/Linux. To do quick build tests in various configurations before
pushing commits, I use a guix.scm[1] file.

With that I'm also testing the build with the Android.mk to find
potential issues.

There are several limitations with the Android.mk build system in Guix.
A well known one is the inability to handle cross compilation, so
people using that build system typically work around that with
something like that[2]:
>        (modify-phases %standard-phases
>          (add-before 'build 'patch-host
>            (lambda _
>              ;; TODO: Cross-compile.
>              (substitute* "Android.mk"
>               (("BUILD_STATIC_LIBRARY") "BUILD_HOST_STATIC_LIBRARY"))
>              #t)))

However I found an issue that is more problematic: this build system
expects an Android.mk with a single target (which is defined
with "LOCAL_MODULE :=" in the Android.mk). 

Until now I didn't implement that in my guix.scm and only built the
library and not the associated utilities.

But then recently I found that the build broke in Android because I
forgot to add some source code files for one of the utilities in the
Android.mk file, so I now really want to build the utilities too in
that guix.scm with the Android.mk build system.

With some help on #guix on liberachat, I managed to run the make
multiple times, and to pass it a list of local-modules to build.

The new build function looks like that[3]:
> (replace 'build
>  (lambda*
>   (#:key inputs make-flags native-inputs outputs #:allow-other-keys)
>    (for-each
>     (lambda (arg)
>      (substitute* "Android.mk"
>       (("BUILD_EXECUTABLE")
>         "BUILD_HOST_EXECUTABLE"))
>       ((assoc-ref %standard-phases 'build)
>        #:make-flags (append make-flags
>                      (list (string-append "LOCAL_MODULE=" arg)))))
>                      ,local-modules)
>   #t))

And the new installation function looks really similar:
> (replace 'install
>  (lambda*
>   (#:key inputs make-flags native-inputs outputs #:allow-other-keys)
>          (for-each
>            (lambda (arg)
>              ((assoc-ref %standard-phases 'install)
>               #:inputs inputs
>               #:outputs outputs
>               #:make-flags
>               (append make-flags
>                       (list (string-append "LOCAL_MODULE=" arg)))))
>            ,local-modules)
>           #t))

But it then ends up building the first local-module in the local-modules
list, many times, and install it with different names.

After building, we can see that https-send-sms was built correctly:
> $ /gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/https-send-sms 
> Usage:
> /gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/https-send-sms
> free-mobile <username> <token> <message>
> 
> Example:
> 	/gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/https-send-sms
> free-mobile "12345678" "1234abcdEFGH" "hello world!"
> $ /gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/ipc-test

But the same source code was also used to build ipc-test
> Usage: /gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/ipc-test free-mobile <username> <token> <message>
> 
> Example:
> 	/gnu/store/[...]-libsamsung-ipc-gcc-android-0.0-HEAD.c4d664a/bin/ipc-test free-mobile "12345678" "1234abcdEFGH" "hello world!"

And if ipc-test source code was used we would end up with something
like that instead:
> $ ipc-test
> Creating client failed

So I'm a bit confused on how to solve this issue. I'm also not sure if
it needs to be solved in Guix or in the underlying Makefiles that
makes it possible to use Android.mk files under GNU/Linux.

I'm writing that mail in the hope that people who knows better the
implementation of the Android.mk build system in Guix would have
pointers to help me solve that issue.

References:
-----------
[1]https://git.replicant.us/replicant/hardware_replicant_libsamsung-ipc/plain/scripts/guix.scm
[2]from android-safe-iop from gnu/packages/android.scm in Guix
[3]https://git.replicant.us/contrib/GNUtoo/replicant/hardware_replicant_libsamsung-ipc/plain/scripts/guix.scm?h=c4d664ae71eb65415d799ada8018cfa49f6fb7fb

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Android.mk build system limitations

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Wed, 6 Jul 2022 17:20:27 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
> But it then ends up building the first local-module in the
> local-modules list, many times, and install it with different names.
In my previous tests https-send-sms was first in both the local-modules
list and in the BUILD_EXECUTABLE modules in the Android.mk.

After some more tests, I found out that it takes the source code from
the first target in the Android.mk and apparently not from the
LOCAL_MODULE= argument passed to make.

Though it uses the name of the produced binary from the LOCAL_MODULE=
argument.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Android.mk build system limitations

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Sat, 9 Jul 2022 14:57:10 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:

> On Wed, 6 Jul 2022 17:20:27 +0200
> Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
> > But it then ends up building the first local-module in the
> > local-modules list, many times, and install it with different names.
> In my previous tests https-send-sms was first in both the
> local-modules list and in the BUILD_EXECUTABLE modules in the
> Android.mk.
> 
> After some more tests, I found out that it takes the source code from
> the first target in the Android.mk and apparently not from the
> LOCAL_MODULE= argument passed to make.
> 
> Though it uses the name of the produced binary from the LOCAL_MODULE=
> argument.
Apparently the issue doesn't seems to be in Guix but in
android-make-stub: android-make-stub seems to be made for only one
target at a time.

A solution would probably be to teach android-make-stub to be able to
only build a given local-module in an Android.mk with many local
modules.

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Android.mk build system limitations

[Denis 'GNUtoo' Carikli]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

On Sat, 9 Jul 2022 21:17:27 +0200
Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org> wrote:
> Apparently the issue doesn't seems to be in Guix but in
> android-make-stub: android-make-stub seems to be made for only one
> target at a time.
With all my modifications for my tests, I forgot that by default it
compiled all the HOST targets it founds.

So if I use the defaults, and make all the include $(BUILD_*) become
include $(BUILD_HOST_*), it would try to build all local modules.

It builds them in the order in which they are declared inside the
Android.mk.

The android-make-stub current design prevents it from being able to
parse dependencies correctly:
- It will not build the local modules dependencies before the local
  module(s) that use them unless they are in that order in the
  Android.mk.
- It can link the local module(s) executable(s) against the local
  modules libraries but if the local modules libraries also need to be
  linked to other libraries, it won't try to link the local module
  executable(s) to these other libraries, and the build will fail.

The advantage of the current design is that the android-make-stub code
is relatively simple to understand and contribute to.

android-make-stub also had an issue with includes but that was a bug
and not a limitation of the current design.

So I've sent a patch serie to android-make-stub[1] to address theses
issues, however it won't be able to fix the design limitations.

So once that serie is merged, and android-make-stub is updated in Guix,
we'd still need to workaround the design limitations in guix by:
- Passing some extra libraries to LDFLAGS
- When multiple LOCAL_MODULE are in the Android.mk, and that the build
  order doesn't match the declaration order, we'd need to run make with
  LOCAL_MODULE=<module> for each module to build. The guix.scm I
  mentioned earlier has some example of how to do that.

I'll send patches or open bug reports to update android-make-stub when
that merge is done. And I'll then use the workarounds mentioned above
in my guix.scm to workaround the limitations of android-make-stub.

References:
-----------
[1]https://github.com/daym/android-make-stub/pull/1

Denis.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]