Hi Po Lu,
> utmpx.h is provided by this new release of the Android NDK, defining
> functions as nonfunctional as utmp.h does.
So, HAVE_UTMPX_H now is 1.
And utmpname exists but utmpxname does not exist. Therefore UTMP_NAME_FUNCTION
is no longer defined.
> The more pressing problem is that its p
Paul Eggert writes:
> On 2024-01-20 19:38, Po Lu wrote:
>> the problem affects the boot-time module rather than
>> readutmp, which Emacs doesn't import. And in the words of Bruno, a
>> functional utmp(x) might appear in Android someday, which binaries
>> compiled today should take advantage of w
On 2024-01-20 19:38, Po Lu wrote:
the problem affects the boot-time module rather than
readutmp, which Emacs doesn't import. And in the words of Bruno, a
functional utmp(x) might appear in Android someday, which binaries
compiled today should take advantage of wherever available.
Oh, I see I w
Paul Eggert writes:
> Thanks for reporting that. Would something like the attached Gnulib
> patch fix the Android issue?
>
> This patch assumes that readutmp-like functions have never worked on
> Android (always report nothing); is that the case?
That is true, but the problem affects the boot-ti
Thanks for reporting that. Would something like the attached Gnulib
patch fix the Android issue?
This patch assumes that readutmp-like functions have never worked on
Android (always report nothing); is that the case?
I haven't installed this, or tested it on Android.From 60aa07c1ccd5aa18a9f87
utmpx.h is provided by this new release of the Android NDK, defining
functions as nonfunctional as utmp.h does.
The more pressing problem is that its presence suppresses the definition
of UTMP_NAME_FUNCTION when a program is built with an __ANDROID_API__
lower than 34, where the utmpx* series of f
