Po Lu wrote:
> With the NDK 16.1.4479499 and __ANDROID_API__ set to 8, utimensat and
> ftruncate appear in libc.so but not in the system headers.

Thanks for the report. The problem, however, is much larger than these
two symbols. Previously I handled the __INTRODUCED_IN that I found in
the Termux /usr/include files. But you are right: Any developer can use
any NDK from 16b to 25b, since these are those than a developer can
currently download through Android Studio.

In a first step, I searched for the symbols marked with
  __INTRODUCED_IN(x)
or
  __INTRODUCED_IN_NO_GUARD_FOR_NDK(x)
for x = 2 ... 35. This gave me the symbol lists in the attached
android-introduced.zip.

In a second step, I looked for occurrences to AC_CHECK_FUNC[S]
or AC_CHECK_FUNCS_ONCE of these symbols. E.g.
  for s in `cat in-8.txt`; do grep -rw "$s" m4 modules | grep CHECK_FUNC; echo ; done
and replaced these with gl_CHECK_FUNCS_ANDROID invocations.

> REPLACE_UTIMENSAT is not defined.

For the moment, it appears OK to treat these symbols like absent
from the header files and from libc (i.e. HAVE_UTIMENSAT=0).

In theory, you are right: it will be better to mark them as REPLACEd,
so that Gnulib will define a function named 'rpl_utimensat' rather than
'utimensat'. But as this matters only for rare situations with shared
libraries (since on Android, everything links against libc.so, not libc.a),
it can wait a bit.

Here's my current work-in-progress; I'll continue with it tomorrow.