Automatically pull in libandroid-posix-semaphore and libandroid-shmem?

[SamB]

Issue #9951 pointed out that:

For libandroid-posix-semaphore (#9559) and libandroid-shmem (#9560), we have modified public headers so that they do not declare some libc symbols but instead declare symbols prefixed by libandroid_ defined in libandroid-* libraries.

... and suggested that it would be a good idea to check for unresolved references to those symbols during package build.

While it is certainly helpful to avoid shipping shared libraries with unresolved references to symbols from these libraries, it would be even more helpful to pull in those libraries automatically, rather than needing to patch the buildsystem for every piece of software that ends up trying to use these functions, even unpackaged stuff.

This would probably need to be done using a variant of the trick used by glibc's libc.so, which is actually a linker script. For example, on Debian arm64, libc.so is:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-littleaarch64)
GROUP ( /lib/aarch64-linux-gnu/libc.so.6 /usr/lib/aarch64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux-aarch64.so.1 ) )

We can be sure that the linker supports this, as otherwise it won't work with stock builds of GNU libc, and the chances that Termux ships an ELF linker before somebody adds GNU/Linux support to it are approximately zero.

The OUTPUT_FORMAT bit is apparently there to prevent wrong-arch use, see https://sourceware.org/git?p=glibc.git;a=blob;f=Makerules;hb=734e7f91e752f44984fe42c2384c23a0290b6e56#l987. The libc_nonshared.a part is irrelevant for us; all we want is to pull in the real libc.so and, AS_NEEDED, whichever libandroid-*.so might be needed.

The main wrinkle is that whatever package shipped such a libc.so would probably need Depends: on the package shipping the libraries listed in AS_NEEDED. (A smaller wrinkle is that you clearly need an explicit path for at least the real libc.so.)

Context: trying to build ocaml on my phone, not sure if there is a way to say "literally everything should be linked against these libraries" or even a single place to patch.

Definitely not trying to package it at the moment.

[truboxl]

and suggested that it would be a good idea to check for unresolved references to those symbols during package build.

https://github.com/termux/termux-packages/blob/ecceef36851d6edf1d6d602abb3ac2cea2fe4bba/scripts/build/termux_step_massage.sh#L185 Already doing that

it would be even more helpful to pull in those libraries automatically, rather than needing to patch the buildsystem for every piece of software that ends up trying to use these functions, even unpackaged stuff

The build will fail if a dependency is missing either reported by the source code build system, or linker error or compiler error. In addition of symbol checks, I think we have pretty wide coverage.

Those libraries are Termux specific and if upstream can accept PR to add support then it's good. Otherwise I don't understand manually adding a few lines of LDFLAGS requires too much effort that warrant automatically pulling.

trying to build ocaml on my phone, not sure if there is a way to say "literally everything should be linked against these libraries" or even a single place to patch.

No point adding all the packages as dependencies when not all of them are used.

If you just want ocaml then file a package request issue. We can restore https://github.com/termux/termux-packages/blob/ecceef36851d6edf1d6d602abb3ac2cea2fe4bba/disabled-packages/ocaml/build.sh accordingly.