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
