Paul Eggert wrote: > > + gl_CHECK_FUNCS_ANDROID([utimensat], [[#include <sys/stat.h>]]) > > if test $ac_cv_func_utimensat = no; then > > HAVE_UTIMENSAT=0 > > + REPLACE_UTIMENSAT=1 > > REPLACE_UTIMENSAT=1 means utimensat is present but broken and needs to > be replaced. However, $ac_cv_func_utimensat = no means utimensat is > absent. So I'm puzzled as to why REPLACE_UTIMENSAT=1 would be > appropriate here.
Deployment on Android is a bit special: When a developer compiles an app, they specify an "API level". This API level designates the minimum Android version on which the app will work. For example [1][2]: 18 = Android 4.3 19 = Android 4.4 20 = Android 4.4W 21 = Android 5.0 22 = Android 5.1 23 = Android 6.0 24 = Android 7.0 25 = Android 7.1 26 = Android 8.0 27 = Android 8.1 28 = Android 9 29 = Android 10 30 = Android 11 31 = Android 12 32 = Android 12L 33 = Android 13 Now, some functions get added to libc over time. For example, the glob and globfree functions are being added in API level 28. So, when a developer *compiles* for an API level < 28 but tests the app on a device with API level ≥ 28, the two functions will not be declared in the header files but will be present in libc. By the way the gl_CHECK_FUNCS_ANDROID macro works so far, when a function is not declared, it reports it as "missing" (ac_cv_func_...=no). This is a good approximation, and will usually work fine. But there is a conflict: Gnulib, when ac_cv_func_glob=no, will define the function 'glob' (not 'rpl_glob'), since Gnulib so far assumes that a build is for one OS version. So, we can arrive at a situation where - the OS defines 'glob' in libc.so, and - the app defines 'glob' in its shared library. By ELF rules, the 'glob' symbol from the app's shared library will override the one from libc. Which is OK for the app. But some calls from within libc might behave unexpectedly if they suddenly call the 'glob' function from the app. Defining REPLACE_GLOB=1 despite HAVE_GLOB=0 will be the way to make Gnulib define 'rpl_glob' instead of 'glob', so that there is no conflict with libc.so. I still need to work out the details how this would/will work. So as to do things correctly on Android, while OTOH not adding lots of configure tests for the other platforms... Bruno [1] https://developer.android.com/studio/releases/platforms [2] https://apilevels.com/
