Re: Android port

Re: Android port

[Angelo Graziosi]

> Also, would someone ascertain if the branch still builds on MS Windows, after the past few updates from Gnulib?

No, on MSYS2/MINGW64 it fails:

============================
[...]
 ===> Building ...

make actual-all || make advice-on-failure make-target=all exit-status=$?
make[1]: ingresso nella directory «/tmp/emacs-master»
make -C lib all
make -C doc/lispref info
make -C doc/lispintro info
make -C doc/emacs info
make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispintro»
/usr/bin/mkdir -p ../../info
make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispref»
/usr/bin/mkdir -p ../../info
  GEN      info/dir
  GEN      ../../info/eintr.info
make[2]: ingresso nella directory «/tmp/emacs-master/doc/emacs»
  GEN      ../../info/emacs.info
  GEN      ../../info/elisp.info
make[2]: ingresso nella directory «/tmp/emacs-master/lib»
  GEN      alloca.h
  GEN      byteswap.h
  GEN      errno.h
  GEN      execinfo.h
  GEN      getopt.h
  GEN      getopt-cdefs.h
  GEN      malloc/dynarray.gl.h
  GEN      malloc/dynarray-skeleton.gl.h
  GEN      ieee754.h
  GEN      limits.h
  GEN      stdckdint.h
  GEN      stddef.h
  GEN      stdint.h
  GEN      string.h
  GEN      sys/random.h
  GEN      time.h
  CC       fingerprint.o
  CC       acl_entries.o
  CC       asnprintf.o
  CC       asprintf.o
  CC       frexp.o
  CC       memmem.o
  CC       mktime.o
  CC       printf.o
asprintf.c:30:1: error: redefinition of 'asprintf'
   30 | asprintf (char **resultp, const char *format, ...)
      | ^~~~~~~~
In file included from C:/msys64/tmp/emacs-master/nt/inc/ms-w32.h:389,
                 from ../src/conf_post.h:38,
                 from ../src/config.h:3511,
                 from asprintf.c:18:
C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
  276 | int asprintf(char **__ret, const char *__format, ...)
      |     ^~~~~~~~
make[2]: *** [Makefile:102: asprintf.o] Error 1
make[2]: *** Attesa per i processi non terminati....
make[2]: uscita dalla directory «/tmp/emacs-master/lib»
make[1]: *** [Makefile:537: lib] Error 2
make[1]: *** Attesa per i processi non terminati....
make[2]: uscita dalla directory «/tmp/emacs-master/doc/lispintro»
make[2]: uscita dalla directory «/tmp/emacs-master/doc/emacs»
make[2]: uscita dalla directory «/tmp/emacs-master/doc/lispref»
make[1]: uscita dalla directory «/tmp/emacs-master»
make[1]: ingresso nella directory «/tmp/emacs-master»
***
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
***   to further investigate the problem
***
make[1]: *** [Makefile:418: advice-on-failure] Error 2
make[1]: uscita dalla directory «/tmp/emacs-master»
make: *** [Makefile:374: all] Error 2
Error: Failure running MAKE
============================

Re: Android port

[Eli Zaretskii]

> Date: Fri, 4 Aug 2023 09:42:44 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> 
> > Also, would someone ascertain if the branch still builds on MS Windows, after the past few updates from Gnulib?
> 
> No, on MSYS2/MINGW64 it fails:
> 
> ============================
> [...]
>  ===> Building ...
> [...]
> asprintf.c:30:1: error: redefinition of 'asprintf'
>    30 | asprintf (char **resultp, const char *format, ...)
>       | ^~~~~~~~
> In file included from C:/msys64/tmp/emacs-master/nt/inc/ms-w32.h:389,
>                  from ../src/conf_post.h:38,
>                  from ../src/config.h:3511,
>                  from asprintf.c:18:
> C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
>   276 | int asprintf(char **__ret, const char *__format, ...)
>       |     ^~~~~~~~

Is asprintf used in any code that needs to be run in the MS-Windows
build of Emacs?  If not, then the easiest solution is to disable
building Gnulib's asprintf via nt/gnulib-cfg.mk.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is asprintf used in any code that needs to be run in the MS-Windows
> build of Emacs?  If not, then the easiest solution is to disable
> building Gnulib's asprintf via nt/gnulib-cfg.mk.

No, the Gnulib folks added two new checks to vasnprintf.m4 reflecting
new C2X features, that weren't present the last time I fixed the Windows
build.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Angelo Graziosi <angelo.g0@libero.it>,  emacs-devel@gnu.org
> Date: Fri, 04 Aug 2023 17:45:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is asprintf used in any code that needs to be run in the MS-Windows
> > build of Emacs?  If not, then the easiest solution is to disable
> > building Gnulib's asprintf via nt/gnulib-cfg.mk.
> 
> No, the Gnulib folks added two new checks to vasnprintf.m4 reflecting
> new C2X features, that weren't present the last time I fixed the Windows
> build.

That doesn't answer my question, AFAICT.  In the current master we
have no uses of asprintf and vasnprintf, so I asked whether it is
needed on the branch, and if so, whether the MS-Windows build uses the
code where these two functions are called.

The way to override Gnulib tests that conclude that some libc function
should be replaced is not to override the feature test (unless that
feature is supported, but Gnulib doesn't know about it -- which can
only happen if we implement the library function inside Emacs).  The
way to override those is to exclude the relevant Gnulib modules from
the Windows build via nt/gnulib-cfg.mk.  If that is not appropriate,
i.e. if the Gnulib module _is_ actually required in the MS-Windows
build, then this is a Gnulib bug that should be reported to them and
fixed by them (but in that case you cannot merge the branch until the
Gnulib folks provide the fix).

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That doesn't answer my question, AFAICT.  In the current master we
> have no uses of asprintf and vasnprintf, so I asked whether it is
> needed on the branch, and if so, whether the MS-Windows build uses the
> code where these two functions are called.

It doesn't, but vfprintf-posix actually replaces all the printf
functions, not just (vasn)printf.  The replacement functions are not
necessary on Windows, however.

> The way to override Gnulib tests that conclude that some libc function
> should be replaced is not to override the feature test (unless that
> feature is supported, but Gnulib doesn't know about it -- which can
> only happen if we implement the library function inside Emacs).  The
> way to override those is to exclude the relevant Gnulib modules from
> the Windows build via nt/gnulib-cfg.mk.

There is already:

OMIT_GNULIB_MODULE_vasnprintf = true
OMIT_GNULIB_MODULE_vasprintf = true
OMIT_GNULIB_MODULE_vfprintf-posix = true

within gnulib-cfg.mk, but fudging with the feature tests is also
necessary to generate the Gnulib stdio.h header correctly; absent that,
it tries to provide definitions for its printf replacements, which does
not work.

IIRC manipulating the feature tests in such a fashion was proposed by
one of the Gnulib developers when the W32 build was last tested in
March, but my memory of that is indistinct and I might've read this
elsewhere.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Fri, 04 Aug 2023 20:12:24 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That doesn't answer my question, AFAICT.  In the current master we
> > have no uses of asprintf and vasnprintf, so I asked whether it is
> > needed on the branch, and if so, whether the MS-Windows build uses the
> > code where these two functions are called.
> 
> It doesn't, but vfprintf-posix actually replaces all the printf
> functions, not just (vasn)printf.  The replacement functions are not
> necessary on Windows, however.

Then TRT is to disable the build of vfprintf-posix module on Windows.

> > The way to override Gnulib tests that conclude that some libc function
> > should be replaced is not to override the feature test (unless that
> > feature is supported, but Gnulib doesn't know about it -- which can
> > only happen if we implement the library function inside Emacs).  The
> > way to override those is to exclude the relevant Gnulib modules from
> > the Windows build via nt/gnulib-cfg.mk.
> 
> There is already:
> 
> OMIT_GNULIB_MODULE_vasnprintf = true
> OMIT_GNULIB_MODULE_vasprintf = true
> OMIT_GNULIB_MODULE_vfprintf-posix = true
> 
> within gnulib-cfg.mk, but fudging with the feature tests is also
> necessary to generate the Gnulib stdio.h header correctly; absent that,
> it tries to provide definitions for its printf replacements, which does
> not work.

OK, then I guess there's something else at work here.  In any case,
the information posted by Angelo clearly shows that asprintf.c is
being compiled, and that is strange if vfprintf-posix module is
disabled.  Maybe we also need

  OMIT_GNULIB_MODULE_asprintf = true

?

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
>> Date: Fri, 04 Aug 2023 20:12:24 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > That doesn't answer my question, AFAICT.  In the current master we
>> > have no uses of asprintf and vasnprintf, so I asked whether it is
>> > needed on the branch, and if so, whether the MS-Windows build uses the
>> > code where these two functions are called.
>> 
>> It doesn't, but vfprintf-posix actually replaces all the printf
>> functions, not just (vasn)printf.  The replacement functions are not
>> necessary on Windows, however.
>
> Then TRT is to disable the build of vfprintf-posix module on Windows.
>
>> > The way to override Gnulib tests that conclude that some libc function
>> > should be replaced is not to override the feature test (unless that
>> > feature is supported, but Gnulib doesn't know about it -- which can
>> > only happen if we implement the library function inside Emacs).  The
>> > way to override those is to exclude the relevant Gnulib modules from
>> > the Windows build via nt/gnulib-cfg.mk.
>> 
>> There is already:
>> 
>> OMIT_GNULIB_MODULE_vasnprintf = true
>> OMIT_GNULIB_MODULE_vasprintf = true
>> OMIT_GNULIB_MODULE_vfprintf-posix = true
>> 
>> within gnulib-cfg.mk, but fudging with the feature tests is also
>> necessary to generate the Gnulib stdio.h header correctly; absent that,
>> it tries to provide definitions for its printf replacements, which does
>> not work.
>
> OK, then I guess there's something else at work here.  In any case,
> the information posted by Angelo clearly shows that asprintf.c is
> being compiled, and that is strange if vfprintf-posix module is
> disabled.  Maybe we also need
>
>   OMIT_GNULIB_MODULE_asprintf = true
>
> ?

There's no module by that name; asprintf is a constituent of vasnprintf,
and that's already mentioned in gnulib-cfg.mk...

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Fri, 04 Aug 2023 21:23:04 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, then I guess there's something else at work here.  In any case,
> > the information posted by Angelo clearly shows that asprintf.c is
> > being compiled, and that is strange if vfprintf-posix module is
> > disabled.  Maybe we also need
> >
> >   OMIT_GNULIB_MODULE_asprintf = true
> >
> > ?
> 
> There's no module by that name; asprintf is a constituent of vasnprintf,
> and that's already mentioned in gnulib-cfg.mk...

When why is asprintf.c being compiled, if its module is disabled?
Disabling a module should disable the lib/Makefile rules that compile
the module.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> When why is asprintf.c being compiled, if its module is disabled?

Because the Gnulib configury includes it within LIBOBJ:

AC_DEFUN([gl_REPLACE_VASPRINTF],
[
  AC_LIBOBJ([vasprintf])
  AC_LIBOBJ([asprintf])
  AC_REQUIRE([gl_STDIO_H_DEFAULTS])

whenever it detects that asprintf isn't present on the host system.

> Disabling a module should disable the lib/Makefile rules that compile
> the module.

Gnulib doesn't support disabling these modules through Makefile options.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 08:48:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > When why is asprintf.c being compiled, if its module is disabled?
> 
> Because the Gnulib configury includes it within LIBOBJ:
> 
> AC_DEFUN([gl_REPLACE_VASPRINTF],
> [
>   AC_LIBOBJ([vasprintf])
>   AC_LIBOBJ([asprintf])
>   AC_REQUIRE([gl_STDIO_H_DEFAULTS])
> 
> whenever it detects that asprintf isn't present on the host system.

What is gl_REPLACE_VASPRINTF, and why is it set for MinGW?  Can that
be disabled somehow (without setting configure variables that test
specific features)?

> > Disabling a module should disable the lib/Makefile rules that compile
> > the module.
> 
> Gnulib doesn't support disabling these modules through Makefile options.

Then we should ask them to add that, or help us solve this in another
proper way.

Paul and Bruno, can you please advise how to resolve this issue?  We
need to disable the compilation of these *printf modules on
MS-Windows, since the Windows build doesn't need them, and compiling
them causes compile-time errors.  The usual method of omitting a
module, like we do in nt/gnulib-cfg.mk, seems not to work in the above
case for some reason.

Another possible way forward is for Gnulib to modify asprintf.c so
that it does compile with MinGW (and then it will be left unused on
Windows in libgnu.a).

TIA

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What is gl_REPLACE_VASPRINTF, and why is it set for MinGW?  Can that
> be disabled somehow (without setting configure variables that test
> specific features)?

gl_REPLACE_VASPRINTF is a macro that is expanded into configure.ac by
gnulib-comp.m4, and acts upon the results of the aformentioned printf
tests.

> Then we should ask them to add that, or help us solve this in another
> proper way.

AFAIK, lying to configure _is_ the proper way for this specific
module...

> Paul and Bruno, can you please advise how to resolve this issue?  We
> need to disable the compilation of these *printf modules on
> MS-Windows, since the Windows build doesn't need them, and compiling
> them causes compile-time errors.  The usual method of omitting a
> module, like we do in nt/gnulib-cfg.mk, seems not to work in the above
> case for some reason.

Yes, please.  Thanks in advance.

Re: Android port

[Angelo Graziosi]

The last android branch builds on NS (macOS 10.13.6 HS).

Anyway I discovered an issue with this branch, both on Windows (yesterday build) and NS (today build), when upgrading packages.

 M-x list-packages
 U
 x

it fails: in the minibuffer I get

[y-or-n-p:] Symbol’s function definition is void: set-text-conversion-style


With current master it works as expected...

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> The last android branch builds on NS (macOS 10.13.6 HS).
>
> Anyway I discovered an issue with this branch, both on Windows
> (yesterday build) and NS (today build), when upgrading packages.
>
>  M-x list-packages
>  U
>  x
>
> it fails: in the minibuffer I get
>
> [y-or-n-p:] Symbol’s function definition is void: set-text-conversion-style
>
>
> With current master it works as expected...

Thanks.  This will be fixed shortly.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> Then we should ask them to add that, or help us solve this in another
> proper way.
> 
> Paul and Bruno, can you please advise how to resolve this issue?  We
> need to disable the compilation of these *printf modules on
> MS-Windows, since the Windows build doesn't need them, and compiling
> them causes compile-time errors.  The usual method of omitting a
> module, like we do in nt/gnulib-cfg.mk, seems not to work in the above
> case for some reason.
> 
> Another possible way forward is for Gnulib to modify asprintf.c so
> that it does compile with MinGW (and then it will be left unused on
> Windows in libgnu.a).

Before thinking about how to disable things, the first thought should
be how to fix the compilation error — since that's generally easier
and also may help other packages than Emacs.

This asprintf() declaration in mingw's <stdio.h> is guarded by
__USE_MINGW_ANSI_STDIO. I've checked the Emacs source code, and it
appears to set __USE_MINGW_ANSI_STDIO to 1, just like Gnulib does.

Therefore I need more info from the reporter (Angelo [1]), for analysis:

1) Please do "make -k V=1" twice and attach the log of the second run.
   (Logs without V=1 often hide important details. Also, I'd like to
   know whether the same error also occurs with vasprintf.c.)

2) Please attach the file config.status. I need to the see value of
   REPLACE_ASPRINTF and related variables.

3) Also, if you still have the output of 'configure' (the many
   "checking for ..." lines), it would be good if you could attach
   that as well.

4) Finally, please attach the C:/msys64/mingw64/include/stdio.h — because
   there are so many versions of mingw.

Thanks.

Bruno

[1] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00044.html

Re: Android port

[Angelo Graziosi]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]


> Il 05/08/2023 12:04 CEST Bruno Haible ha scritto:
> [...]
> Therefore I need more info from the reporter (Angelo [1]), for analysis:
> 
> 1) Please do "make -k V=1" twice and attach the log of the second run.
>    (Logs without V=1 often hide important details. Also, I'd like to
>    know whether the same error also occurs with vasprintf.c.)
> 
> 2) Please attach the file config.status. I need to the see value of
>    REPLACE_ASPRINTF and related variables.
> 
> 3) Also, if you still have the output of 'configure' (the many
>    "checking for ..." lines), it would be good if you could attach
>    that as well.
> 
> 4) Finally, please attach the C:/msys64/mingw64/include/stdio.h — because
>    there are so many versions of mingw.
> 
> Thanks.
> 
> Bruno
> 
> [1] https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00044.html

I had lost that source but 

wget https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz

seems the same source. It has the same failure.

The attached tarball contains:

- autogen_configure_output.log, which is the output of
  
    ./autogen
    ./configure

- make-k_V.eq.1-first_output.log, which is the output of the first `make -k V=1`
- make-k_V.eq.1-second_output.log, which is the output of the first `make -k V=1`
- config.status
- stdio.h (/mingw64/include/stdio.h)

Angelo

[-- Attachment #2: emacs_build_logs.tar.gz --]
[-- Type: application/gzip, Size: 48713 bytes --]

Re: Android port

[Bruno Haible]

Angelo Graziosi wrote:
> I had lost that source but 
> 
> wget https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz
> 
> seems the same source. It has the same failure.
> 
> The attached tarball contains:
> 
> - autogen_configure_output.log, which is the output of
>   
>     ./autogen
>     ./configure
> 
> - make-k_V.eq.1-first_output.log, which is the output of the first `make -k V=1`
> - make-k_V.eq.1-second_output.log, which is the output of the first `make -k V=1`
> - config.status
> - stdio.h (/mingw64/include/stdio.h)

Thanks. The REPLACE_*PRINTF values appear to be correct.

But from this error log:

In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
                 from ../src/conf_post.h:38,
                 from ../src/config.h:3511,
                 from printf.c:18:
C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'

it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
the interposed lib/stdio.h.

Do you have a lib/stdio.h in your build tree?

Bruno

Re: Android port

[Angelo Graziosi]

> Il 05/08/2023 13:20 CEST Bruno Haible ha scritto:
> 
>  
> Angelo Graziosi wrote:
> > I had lost that source but 
> > 
> > wget https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz
> > 
> > seems the same source. It has the same failure.
> > 
> > The attached tarball contains:
> > 
> > - autogen_configure_output.log, which is the output of
> >   
> >     ./autogen
> >     ./configure
> > 
> > - make-k_V.eq.1-first_output.log, which is the output of the first `make -k V=1`
> > - make-k_V.eq.1-second_output.log, which is the output of the first `make -k V=1`
> > - config.status
> > - stdio.h (/mingw64/include/stdio.h)
> 
> Thanks. The REPLACE_*PRINTF values appear to be correct.
> 
> But from this error log:
> 
> In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
>                  from ../src/conf_post.h:38,
>                  from ../src/config.h:3511,
>                  from printf.c:18:
> C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'
> 
> it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
> the interposed lib/stdio.h.
> 
> Do you have a lib/stdio.h in your build tree?

It seems no, just something similar:

$ ls  emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/std*
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdalign.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdckdint.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdckdint.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stddef.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stddef.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdint.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdint.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdio.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdio-impl.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdlib.in.h


and

$ find emacs-bfbdf4eb892935536fc665d6cc986fd669364263/ -iname "*stdio*"
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/cross/lib/stdio-impl.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/cross/lib/stdio.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdio-impl.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib/stdio.in.h
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/m4/stdio_h.m4
emacs-bfbdf4eb892935536fc665d6cc986fd669364263/src/sysstdio.h

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: Po Lu <luangruo@yahoo.com>, Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 13:20:31 +0200
> 
> But from this error log:
> 
> In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
>                  from ../src/conf_post.h:38,
>                  from ../src/config.h:3511,
>                  from printf.c:18:
> C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'
> 
> it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
> the interposed lib/stdio.h.
> 
> Do you have a lib/stdio.h in your build tree?

The MinGW build omits building the Gnulib's stdio module.  We did that
since 2017.  The exact reasons are probably lost in time, but I can
assure you they were real, and I wouldn't want to reintroduce them for
this particular reason.

Since the *printf family doesn't need to be replaced in the Emacs
build on MS-Windows, I'd rather we understood why the above causes
compilation errors.  Aren't Gnulib replacements for *printf functions
supposed to have prototypes compatible to the MinGW headers?

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Haible <bruno@clisp.org>
>> Cc: Po Lu <luangruo@yahoo.com>, Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Sat, 05 Aug 2023 13:20:31 +0200
>> 
>> But from this error log:
>> 
>> In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
>>                  from ../src/conf_post.h:38,
>>                  from ../src/config.h:3511,
>>                  from printf.c:18:
>> C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'
>> 
>> it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
>> the interposed lib/stdio.h.
>> 
>> Do you have a lib/stdio.h in your build tree?
>
> The MinGW build omits building the Gnulib's stdio module.  We did that
> since 2017.  The exact reasons are probably lost in time, but I can
> assure you they were real, and I wouldn't want to reintroduce them for
> this particular reason.
>
> Since the *printf family doesn't need to be replaced in the Emacs
> build on MS-Windows, I'd rather we understood why the above causes
> compilation errors.  Aren't Gnulib replacements for *printf functions
> supposed to have prototypes compatible to the MinGW headers?

Judging from the headers Angelo provided, the issue lies in MinGW's
headers defining (not merely declaring) asprintf:

#ifdef _GNU_SOURCE
__mingw_ovr
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
  int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vasprintf( __ret, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

IMHO, the least risky solution remains disabling the vasprintf module
entirely.  We can revisit this problem when and if Emacs begins to rely
on ISO C2X and C99 features supplied by Gnulib.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Bruno Haible <bruno@clisp.org>,  angelo.g0@libero.it,
>   eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 20:16:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Since the *printf family doesn't need to be replaced in the Emacs
> > build on MS-Windows, I'd rather we understood why the above causes
> > compilation errors.  Aren't Gnulib replacements for *printf functions
> > supposed to have prototypes compatible to the MinGW headers?
> 
> Judging from the headers Angelo provided, the issue lies in MinGW's
> headers defining (not merely declaring) asprintf:
> 
> #ifdef _GNU_SOURCE
> __mingw_ovr
> __attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
> int asprintf(char **__ret, const char *__format, ...)
> {
>   int __retval;
>   __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
>   __retval = __mingw_vasprintf( __ret, __format, __local_argv );
>   __builtin_va_end( __local_argv );
>   return __retval;
> }
> 
> IMHO, the least risky solution remains disabling the vasprintf module
> entirely.

I agree.  We wanted to do that from the get-go, but you said it was
somehow impossible, or didn't work?

> We can revisit this problem when and if Emacs begins to rely on ISO
> C2X and C99 features supplied by Gnulib.

Right.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I agree.  We wanted to do that from the get-go, but you said it was
> somehow impossible, or didn't work?

That's the subject I'm trying to bring up with Bruno: presently, it's
still impossible to disable printf-related using the
`OMIT_GNULIB_MODULE_' Makefile options, only through manipulating test
results in mingw-cfg.site.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I agree.  We wanted to do that from the get-go, but you said it was
>> somehow impossible, or didn't work?
>
> That's the subject I'm trying to bring up with Bruno: presently, it's
> still impossible to disable printf-related using the
                             ^ the          ^ modules

Sorry about the omissions.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> > But from this error log:
> > 
> > In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
> >                  from ../src/conf_post.h:38,
> >                  from ../src/config.h:3511,
> >                  from printf.c:18:
> > C:/msys64/mingw64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'
> > 
> > it seems that nt/inc/ms-w32.h directly includes <stdio.h> from mingw, without
> > the interposed lib/stdio.h.
> > 
> > Do you have a lib/stdio.h in your build tree?

Angelo replied "It seems no".

And that is the problem. The generated stdio.h, on this platform, is
supposed to contain macro definitions:
  #define asprintf rpl_asprintf
  #define printf __printf__
  #define vasprintf rpl_vasprintf
  #define vfprintf rpl_vfprintf

By omitting these macro definitions, there is a conflict between the
inline definition in mingw's <stdio.h> and the Gnulib replacement code.

> The MinGW build omits building the Gnulib's stdio module.  We did that
> since 2017.  The exact reasons are probably lost in time, but I can
> assure you they were real, and I wouldn't want to reintroduce them for
> this particular reason.

It'd be worth a try nevertheless. Gnulib has changed a lot since 2017.

> Since the *printf family doesn't need to be replaced in the Emacs
> build on MS-Windows, I'd rather we understood why the above causes
> compilation errors.

See above.

> Aren't Gnulib replacements for *printf functions
> supposed to have prototypes compatible to the MinGW headers?

No, Gnulib replacements always have different function names than
the system function (except for the 'free' function). The reason
is that there is so much variation in the prototypes of a function
(with or without 'restrict', with or without 'throw()' in C++,
with or without 'static' / 'inline'), that it would be extremely
fragile to attempt to get the exact same prototype as the system.

So, if you decided not to have a generated stdio.h, the simplest
solution seems to be:
  1) in the conf_post.h or nt/inc/ms-w32.h, include <stdio.h>
     (this is the one from the system),
  2) after this #include, add
     #define asprintf rpl_asprintf
     #define printf __printf__
     #define vasprintf rpl_vasprintf
     #define vfprintf rpl_vfprintf
     and add prototypes for these 4 functions.

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: angelo.g0@libero.it, luangruo@yahoo.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 14:25:59 +0200
> 
> Eli Zaretskii wrote:
> > The MinGW build omits building the Gnulib's stdio module.  We did that
> > since 2017.  The exact reasons are probably lost in time, but I can
> > assure you they were real, and I wouldn't want to reintroduce them for
> > this particular reason.
> 
> It'd be worth a try nevertheless. Gnulib has changed a lot since 2017.

If someone wants to try that and report back, I won't mind.  But I
personally don't have time (nor the motivation, TBH).  There be
dragons: for example, Emacs on MS-Windows provides its own
implementation of fopen, because we want to support UTF-8 encoded file
names even when the system codepage is not (or cannot be) UTF-8.
Likewise with any other Gnulib replacement that accepts file names:
Emacs must be able to pass UTF-8 encoded file names on Windows,
because it supports non-ASCII file names without restrictions imposed
by the current system codepage.

> So, if you decided not to have a generated stdio.h, the simplest
> solution seems to be:
>   1) in the conf_post.h or nt/inc/ms-w32.h, include <stdio.h>
>      (this is the one from the system),
>   2) after this #include, add
>      #define asprintf rpl_asprintf
>      #define printf __printf__
>      #define vasprintf rpl_vasprintf
>      #define vfprintf rpl_vfprintf
>      and add prototypes for these 4 functions.

I'd prefer to use the simpler machinery of OMIT_GNULIB_MODULE to
prevent the Emacs build from compiling asprintf.c and similar
replacements on MS-Windows.  Is that possible?  We do that with
several other Gnulib modules, see the file nt/gnulib-cfg.mk in the
Emacs repository.

Thanks.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> >   2) after this #include, add
> >      #define asprintf rpl_asprintf
> >      #define printf __printf__
> >      #define vasprintf rpl_vasprintf
> >      #define vfprintf rpl_vfprintf
> >      and add prototypes for these 4 functions.
> 
> I'd prefer to use the simpler machinery of OMIT_GNULIB_MODULE to
> prevent the Emacs build from compiling asprintf.c and similar
> replacements on MS-Windows.  Is that possible?

Only Paul can answer this. The OMIT_GNULIB_MODULE mechanism is an Emacs
invention.

Gnulib's mechanism for avoiding modules is the --avoid=<modulename>
option to gnulib-tool. But that omits the module on *all* platforms.
Gnulib's preferred mechanism for tweaking the behaviour on a platform-
by-platform basis is to preset some gl_cv_* variables, so as to
shortcut specific configure tests.

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: angelo.g0@libero.it, luangruo@yahoo.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 14:47:59 +0200
> 
> Eli Zaretskii wrote:
> > >   2) after this #include, add
> > >      #define asprintf rpl_asprintf
> > >      #define printf __printf__
> > >      #define vasprintf rpl_vasprintf
> > >      #define vfprintf rpl_vfprintf
> > >      and add prototypes for these 4 functions.
> > 
> > I'd prefer to use the simpler machinery of OMIT_GNULIB_MODULE to
> > prevent the Emacs build from compiling asprintf.c and similar
> > replacements on MS-Windows.  Is that possible?
> 
> Only Paul can answer this. The OMIT_GNULIB_MODULE mechanism is an Emacs
> invention.

Then I hope Paul chimes in soon.

> Gnulib's mechanism for avoiding modules is the --avoid=<modulename>
> option to gnulib-tool. But that omits the module on *all* platforms.
> Gnulib's preferred mechanism for tweaking the behaviour on a platform-
> by-platform basis is to preset some gl_cv_* variables, so as to
> shortcut specific configure tests.

I prefer not to preset gl_cv_* variables in this case, since they are
general enough tests of specific printf features, and if those
features will ever be really needed in Emacs, we want to be alerted to
that.  We only preset such variables when the corresponding features
are implemented in Emacs's own code (about which the configure script
cannot know), or when it is clear that the features will never be
useful in Emacs on Windows.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I prefer not to preset gl_cv_* variables in this case, since they are
> general enough tests of specific printf features, and if those
> features will ever be really needed in Emacs, we want to be alerted to
> that.

I don't follow this: even if these tests are left intact, how will they
serve to warn us of new dependencies introduced in Emacs?  The results
of the configure tests are irrespective of Emacs source code.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Bruno Haible <bruno@clisp.org>,  angelo.g0@libero.it,
>   eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 21:13:25 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I prefer not to preset gl_cv_* variables in this case, since they are
> > general enough tests of specific printf features, and if those
> > features will ever be really needed in Emacs, we want to be alerted to
> > that.
> 
> I don't follow this: even if these tests are left intact, how will they
> serve to warn us of new dependencies introduced in Emacs?  The results
> of the configure tests are irrespective of Emacs source code.

The results of those tests are logged in config.log.  When we preset
the variables, the tests are not performed and the results are not
recorded anywhere; you just see something like "(cached) yes".

Re: Android port

[Eli Zaretskii]

> Date: Sat, 05 Aug 2023 18:26:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: bruno@clisp.org, angelo.g0@libero.it, eggert@cs.ucla.edu,
>  emacs-devel@gnu.org
> 
> > I don't follow this: even if these tests are left intact, how will they
> > serve to warn us of new dependencies introduced in Emacs?  The results
> > of the configure tests are irrespective of Emacs source code.
> 
> The results of those tests are logged in config.log.  When we preset
> the variables, the tests are not performed and the results are not
> recorded anywhere; you just see something like "(cached) yes".

And in addition, other tests for other Gnulib modules might depend on
the results of these tests.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> And in addition, other tests for other Gnulib modules might depend on
> the results of these tests.

If so, those Gnulib modules will also depend on the *-printf modules, by
all likelihood.  Our attention will be brought to the problem regardless
of how we chose to disable those modules.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bruno@clisp.org,  angelo.g0@libero.it,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 07:37:40 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And in addition, other tests for other Gnulib modules might depend on
> > the results of these tests.
> 
> If so, those Gnulib modules will also depend on the *-printf modules, by
> all likelihood.  Our attention will be brought to the problem regardless
> of how we chose to disable those modules.

It will be harder to figure out, at least.

Look, I'm the only person around here who had ever seriously worked
with these facilities, so please believe me when I say that some ways
are better than others, okay?

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Look, I'm the only person around here who had ever seriously worked
> with these facilities, so please believe me when I say that some ways
> are better than others, okay?

OK, but the Gnulib developers aren't inclined to introduce any changes
for us here.  So we've got to work with what we have, following practice
that already exists within mingw-cfg.site:

# We don't need fdopendir
ac_cv_func_fdopendir="not-needed"
gl_cv_func_fdopendir_works="no-but-not-needed-so-yes"

# Avoid gnulib replacement
gl_threads_api=posix
gl_cv_func_pthread_sigmask_return_works=yes
gl_cv_func_pthread_sigmask_unblock_works="not relevant"
gl_cv_func_pthread_sigmask_macro=no

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: bruno@clisp.org,  angelo.g0@libero.it,  eggert@cs.ucla.edu,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 13:07:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Look, I'm the only person around here who had ever seriously worked
> > with these facilities, so please believe me when I say that some ways
> > are better than others, okay?
> 
> OK, but the Gnulib developers aren't inclined to introduce any changes
> for us here.

Paul didn't chime in yet, so I'd like to wait for him to comment on
this.  I see no reason why we would be unable to omit these modules
like we do with others.

> So we've got to work with what we have, following practice
> that already exists within mingw-cfg.site:
> 
> # We don't need fdopendir
> ac_cv_func_fdopendir="not-needed"
> gl_cv_func_fdopendir_works="no-but-not-needed-so-yes"
> 
> # Avoid gnulib replacement
> gl_threads_api=posix
> gl_cv_func_pthread_sigmask_return_works=yes
> gl_cv_func_pthread_sigmask_unblock_works="not relevant"
> gl_cv_func_pthread_sigmask_macro=no

There are good reasons for those (and others like them).  fdopendir is
not a feature, it's an API that cannot work on Windows.  And the
pthreads stuff causes Emacs to depend on the pthreads DLL (which is
bad for distributing the binaries), and also replaces some
time-related structure definitions ('struct timespec', I think) with
pthread ones -- and these cannot be undone by omitting some Gnulib
modules.

Like I said: this stuff is done for very good reasons, and only after
careful consideration of the alternatives.  It worked for the last 10
years with almost no changes.

Re: Android port

[Paul Eggert]

On 2023-08-05 22:24, Eli Zaretskii wrote:
> Paul didn't chime in yet, so I'd like to wait for him to comment on
> this.  I see no reason why we would be unable to omit these modules
> like we do with others.

I don't either, but I hope we don't have to worry about it.

As I understand it the Android port uses Gnulib printf-posix and 
vasprintf-posix modules only because Android printf lacks support for 
"%td", "%jd" and "%ju". If this understanding is correct, how about if 
we go through the printf formats in the Emacs C source code, and replace 
all uses of "%jd" and "%ju" with "%"PRIdMAX and "%"PRIuMAX, and all uses 
of "%td" with "%"pT"d" where pT is an Emacs invention defined like this:

  #ifdef __ANDROID__
  # define pT "z"
  #else
  # define pT "t"
  #endif

That way, the Android branch wouldn't need to use the printf-posix and 
vasprintf-posix modules, and we wouldn't have to worry about the hassle 
of porting them into the Emacs world.

Admittedly this hack is not the Gnulib Way, but Emacs departs so far 
from the Gnulib Way that this one extra little thing shouldn't be that 
big of a deal.

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 01:48:40 -0700
> Cc: bruno@clisp.org, angelo.g0@libero.it, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> As I understand it the Android port uses Gnulib printf-posix and 
> vasprintf-posix modules only because Android printf lacks support for 
> "%td", "%jd" and "%ju". If this understanding is correct, how about if 
> we go through the printf formats in the Emacs C source code, and replace 
> all uses of "%jd" and "%ju" with "%"PRIdMAX and "%"PRIuMAX, and all uses 
> of "%td" with "%"pT"d" where pT is an Emacs invention defined like this:
> 
>   #ifdef __ANDROID__
>   # define pT "z"
>   #else
>   # define pT "t"
>   #endif

Fine by me, if this keeps the Android port happy.

Re: Android port

[Po Lu]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2023-08-05 22:24, Eli Zaretskii wrote:
>> Paul didn't chime in yet, so I'd like to wait for him to comment on
>> this.  I see no reason why we would be unable to omit these modules
>> like we do with others.
>
> I don't either, but I hope we don't have to worry about it.
>
> As I understand it the Android port uses Gnulib printf-posix and
> vasprintf-posix modules only because Android printf lacks support for
> "%td", "%jd" and "%ju". If this understanding is correct, how about if
> we go through the printf formats in the Emacs C source code, and
> replace all uses of "%jd" and "%ju" with "%"PRIdMAX and "%"PRIuMAX,
> and all uses of "%td" with "%"pT"d" where pT is an Emacs invention
> defined like this:

And also %n (used in the rest of Emacs), which aborts on Android for
``security'' reasons...

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  bruno@clisp.org,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 17:24:47 +0800
> 
> And also %n (used in the rest of Emacs), which aborts on Android for
> ``security'' reasons...

Most of those are not relevant for Android, right?

The only one which is relevant (in emacs.c) can be rewritten not to
use %n.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Most of those are not relevant for Android, right?

We only have one use of %n, in emacs.c AFAICT.

> The only one which is relevant (in emacs.c) can be rewritten not to
> use %n.

Indeed, but the Proper Way is to use Gnulib.  I'd prefer we tried to
make it work.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: eggert@cs.ucla.edu,  bruno@clisp.org,  angelo.g0@libero.it,
>  emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 17:41:10 +0800
> 
> > The only one which is relevant (in emacs.c) can be rewritten not to
> > use %n.
> 
> Indeed, but the Proper Way is to use Gnulib.  I'd prefer we tried to
> make it work.

If you can figure out why omitting those modules doesn't work, maybe
we could go that way as well.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: eggert@cs.ucla.edu,  bruno@clisp.org,  angelo.g0@libero.it,
>>  emacs-devel@gnu.org
>> Date: Sun, 06 Aug 2023 17:41:10 +0800
>> 
>> > The only one which is relevant (in emacs.c) can be rewritten not to
>> > use %n.
>> 
>> Indeed, but the Proper Way is to use Gnulib.  I'd prefer we tried to
>> make it work.
>
> If you can figure out why omitting those modules doesn't work, maybe
> we could go that way as well.

I thought I did.  Paul, the issue lies in how AC_LIBOBJ is used to
include the files comprising the *printf modules.  The
OMIT_GNULIB_MODULE_xxx stuff cannot function unless gnulib.mk does so
instead.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: eggert@cs.ucla.edu,  bruno@clisp.org,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 17:54:50 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you can figure out why omitting those modules doesn't work, maybe
> > we could go that way as well.
> 
> I thought I did.

You said that those files are included in the list of object files to
build if Gnulib configury detects that asprintf is missing, right?

Then I don't think I understand this, since (a) MinGW64 which Angelo
uses does have asprintf, and (b) we could use the configure variable
that records the existence of asprintf to override that, like we do
with other ac_cv_func_* variables.  But for some reason you didn't use
that variable (or any similar one) in your proposed patch, why?

So to me this issue is still not clear enough.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Then I don't think I understand this, since (a) MinGW64 which Angelo
> uses does have asprintf, and (b) we could use the configure variable
> that records the existence of asprintf to override that, like we do
> with other ac_cv_func_* variables.  But for some reason you didn't use
> that variable (or any similar one) in your proposed patch, why?

That's because my patch was an addendum to changes installed on the
feature/android branch months ago.  The diff between mingw-cfg.site on
the branch and on master is more illustrative:

diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index 425eaace30d..f78ee525bf1 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -173,3 +173,21 @@ gl_cv_func_nanosleep=yes
 # Suppress configure-time diagnostic from unnecessary libxattr check,
 # as xattr will not be supported here.
 enable_xattr=no
+# Don't build gnulib printf either.
+gl_cv_func_printf_sizes_c99=yes
+gl_cv_func_printf_sizes_c23=yes
+gl_cv_func_printf_long_double=yes
+gl_cv_func_printf_infinite_long_double=yes
+gl_cv_func_printf_directive_a=yes
+gl_cv_func_printf_directive_b=yes
+gl_cv_func_printf_directive_f=yes
+gl_cv_func_printf_directive_n=yes
+gl_cv_func_printf_directive_ls=yes
+gl_cv_func_printf_directive_lc=yes
+gl_cv_func_printf_positions=yes
+gl_cv_func_printf_flag_grouping=yes
+gl_cv_func_printf_flag_leftadjust=yes
+gl_cv_func_printf_flag_zero=yes
+gl_cv_func_printf_precision=yes
+gl_cv_func_printf_enomem=yes
+ac_cv_func_vasprintf=yes

Both the check for vasprintf (Gnulib eschews testing for asprintf, since
asprintf is never present where vasprintf is not) and the checks for
printf features are overridden, because Gnulib also tries to replace
vasprintf if it discovers that the conventional printf functions will
need to be replaced.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: eggert@cs.ucla.edu,  bruno@clisp.org,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 18:10:32 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then I don't think I understand this, since (a) MinGW64 which Angelo
> > uses does have asprintf, and (b) we could use the configure variable
> > that records the existence of asprintf to override that, like we do
> > with other ac_cv_func_* variables.  But for some reason you didn't use
> > that variable (or any similar one) in your proposed patch, why?
> 
> That's because my patch was an addendum to changes installed on the
> feature/android branch months ago.  The diff between mingw-cfg.site on
> the branch and on master is more illustrative:
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index 425eaace30d..f78ee525bf1 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -173,3 +173,21 @@ gl_cv_func_nanosleep=yes
>  # Suppress configure-time diagnostic from unnecessary libxattr check,
>  # as xattr will not be supported here.
>  enable_xattr=no
> +# Don't build gnulib printf either.
> +gl_cv_func_printf_sizes_c99=yes
> +gl_cv_func_printf_sizes_c23=yes
> +gl_cv_func_printf_long_double=yes
> +gl_cv_func_printf_infinite_long_double=yes
> +gl_cv_func_printf_directive_a=yes
> +gl_cv_func_printf_directive_b=yes
> +gl_cv_func_printf_directive_f=yes
> +gl_cv_func_printf_directive_n=yes
> +gl_cv_func_printf_directive_ls=yes
> +gl_cv_func_printf_directive_lc=yes
> +gl_cv_func_printf_positions=yes
> +gl_cv_func_printf_flag_grouping=yes
> +gl_cv_func_printf_flag_leftadjust=yes
> +gl_cv_func_printf_flag_zero=yes
> +gl_cv_func_printf_precision=yes
> +gl_cv_func_printf_enomem=yes
> +ac_cv_func_vasprintf=yes

Isn't there some "summary" variable for printf, like
gl_cv_func_printf_works or some such, which is set if all of the above
variables are set?  I'd prefer to override summary if it exists,
rather than each one of the above function-testing variables
individually.

> Both the check for vasprintf (Gnulib eschews testing for asprintf, since
> asprintf is never present where vasprintf is not) and the checks for
> printf features are overridden, because Gnulib also tries to replace
> vasprintf if it discovers that the conventional printf functions will
> need to be replaced.

Perhaps we should ask Gnulib to allow disabling these in a more
convenient manner.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> Isn't there some "summary" variable for printf, like
> gl_cv_func_printf_works or some such, which is set if all of the above
> variables are set?  I'd prefer to override summary if it exists

No, there is no such "summary" variable. And it would be overkill to
introduce one, because
  - Emacs is the only package that needs a certain Gnulib module on
    most platforms but wants to deactivate it on one particular platform.
    Other packages don't work this way.
  - The approach to set the variables individually in mingw-cfg.site
    is good enough. It occasionally needs updates, every N years or so,
    when some variable is added. But that's not a good enough justification
    for adding complexity to Gnulib.

Also, a "summary" variable would not fulfil the goal that you set out
yourself yesterday:
  "I prefer not to preset gl_cv_* variables in this case, since they are
   general enough tests of specific printf features, and if those
   features will ever be really needed in Emacs, we want to be alerted to
   that."

I perfectly understand this argument, that you want to be aware if the
mingw-cfg.site file for example pretends that Emacs does not need %b support,
in order to check the format strings to see whether that's indeed the case.
The individual gl_cv_* variables are the right instrument to achieve this
process.

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 13:02:45 +0200
> 
> Eli Zaretskii wrote:
> > Isn't there some "summary" variable for printf, like
> > gl_cv_func_printf_works or some such, which is set if all of the above
> > variables are set?  I'd prefer to override summary if it exists
> 
> No, there is no such "summary" variable. And it would be overkill to
> introduce one, because
>   - Emacs is the only package that needs a certain Gnulib module on
>     most platforms but wants to deactivate it on one particular platform.
>     Other packages don't work this way.
>   - The approach to set the variables individually in mingw-cfg.site
>     is good enough. It occasionally needs updates, every N years or so,
>     when some variable is added. But that's not a good enough justification
>     for adding complexity to Gnulib.

The decision whether Emacs's needs justify some additional complexity
in Gnulib is yours, of course (although I'd argue that Emacs is not
just any package), but please don't decide for the Emacs maintainers
whether this or that alternative is "good enough" for Emacs.  If we
reach out to Gnulib developers asking them for help in this matter, we
do that in good faith, and _after_ we considered the alternatives
which don't involve Gnulib changes (which are always preferable, for
obvious reasons).

> Also, a "summary" variable would not fulfil the goal that you set out
> yourself yesterday:
>   "I prefer not to preset gl_cv_* variables in this case, since they are
>    general enough tests of specific printf features, and if those
>    features will ever be really needed in Emacs, we want to be alerted to
>    that."
> 
> I perfectly understand this argument, that you want to be aware if the
> mingw-cfg.site file for example pretends that Emacs does not need %b support,
> in order to check the format strings to see whether that's indeed the case.
> The individual gl_cv_* variables are the right instrument to achieve this
> process.

Unless there's a misunderstanding, your understanding contradicts what
I wanted to convey in the quoited text.  The individual gl_cv_*
variables, if overridden by mingw-cfg.site, will completely shadow the
feature tests and will from that moment on make detecting any new
needs for that and dealing with those new needs our responsibility,
with nothing to aid us.  Which in practice means we could have a
broken port on Windows if some other functionality, which _is_ needed
on Windows, will become dependent on a test that we've overridden via
these variables.

Which is why I prefer to disable a module or a function replacement
without overriding the individual functionality tests which led to the
inclusion of the module and/or replacement of a function.  Disabling
the module or a function replacement just says that this
module/function is not needed or is implemented differently, without
saying anything about the respective functionalities.

Disabling functionality tests is only TRT when they are implemented in
Emacs's own code (and thus the configure script cannot possibly know
about them).  And even then we try to minimize the list of disabled
functionalities by telling the configure script as much as we can;
that is the reason why the configure script does this:

      *-mingw* )
                opsys=mingw32
                # MinGW overrides and adds some system headers in nt/inc.
                GCC_TEST_OPTIONS="-I $srcdir/nt/inc"

Re: Android port

[Po Lu]

Everyone,

This conversation is fast on track to becoming unmanageable.  Since the
Gnulib developers believe that the solution presently in place on the
branch is acceptable, and it _does_ work to the best of our knowledge,
how about merging the branch and shelving this conjecture for the time
being?  Personally, I feel that it's unlikely that any other Gnulib
module we import will make use of the test results that are overridden,
as the printf modules are self-contained.  We can always assess the
impact of future changes to Gnulib when they are merged into Emacs.

Thanks.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Bruno Haible <bruno@clisp.org>,  eggert@cs.ucla.edu,
>   angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 20:30:51 +0800
> 
> Everyone,
> 
> This conversation is fast on track to becoming unmanageable.  Since the
> Gnulib developers believe that the solution presently in place on the
> branch is acceptable, and it _does_ work to the best of our knowledge,
> how about merging the branch and shelving this conjecture for the time
> being?  Personally, I feel that it's unlikely that any other Gnulib
> module we import will make use of the test results that are overridden,
> as the printf modules are self-contained.  We can always assess the
> impact of future changes to Gnulib when they are merged into Emacs.

I understand your POV, but I would like to give this discussion some
more time before we make the decision.  We do want to merge the
branch, but a day or two more while we discuss alternatives won't
change anything.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> Unless there's a misunderstanding, your understanding contradicts what
> I wanted to convey in the quoited text.

It's possible that I had misunderstood you. In fact, I don't fully
understand your argument even now:

> The individual gl_cv_*
> variables, if overridden by mingw-cfg.site, will completely shadow the
> feature tests and will from that moment on make detecting any new
> needs for that and dealing with those new needs our responsibility,
> with nothing to aid us.  Which in practice means we could have a
> broken port on Windows if some other functionality, which _is_ needed
> on Windows, will become dependent on a test that we've overridden via
> these variables.
> 
> Which is why I prefer to disable a module or a function replacement
> without overriding the individual functionality tests which led to the
> inclusion of the module and/or replacement of a function.  Disabling
> the module or a function replacement just says that this
> module/function is not needed or is implemented differently, without
> saying anything about the respective functionalities.

I'd like to view this question from the process point-of-view:

If some new functionality test is introduced in gnulib/m4/printf.m4,
be it
  (a) because a bug has been discovered on a non-mingw platform
      (such as recently the %lc bug), or
  (b) because a bug has been discovered on mingw, or
  (c) because a new ISO C or POSIX standard requires new functionalities
      (such as recently the support of %b),
what do you expect to see and do in Emacs?

In all three cases, we update the Gnulib documentation, but don't put
an entry into gnulib/NEWS.

Will you typically want to
  - review all format strings in Emacs, to see whether they are affected?
  - add some note to Emacs-internal coding guidelines, e.g. to the effect
    that %b should not be used?
  - review the mingw-specific *printf override, to see whether it
    needs a workaround (in case b) or an extension (in case c)?
  - or do nothing at all?

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 16:40:10 +0200
> 
> > The individual gl_cv_*
> > variables, if overridden by mingw-cfg.site, will completely shadow the
> > feature tests and will from that moment on make detecting any new
> > needs for that and dealing with those new needs our responsibility,
> > with nothing to aid us.  Which in practice means we could have a
> > broken port on Windows if some other functionality, which _is_ needed
> > on Windows, will become dependent on a test that we've overridden via
> > these variables.
> > 
> > Which is why I prefer to disable a module or a function replacement
> > without overriding the individual functionality tests which led to the
> > inclusion of the module and/or replacement of a function.  Disabling
> > the module or a function replacement just says that this
> > module/function is not needed or is implemented differently, without
> > saying anything about the respective functionalities.

First, the above is only about the MinGW build of Emacs.  We don't
override Gnulib tests and their results on any other platforms
supported by Emacs and by Gnulib.  The reasons for this special
treatment of Gnulib on MinGW are:

 . Emacs supports old versions of Windows while Gnulib dropped their
   support, so we cannot use Gnulib functions which will fail on those
   older Windows versions (e.g., because Gnulib assumes some API to be
   always present which is not available on old Windows versions, or
   needs to be manually loaded from some DLL);
 . Emacs supports UTF-8 encoded file names by converting them to
   UTF-16 and using "wide" APIs to access such file, something Gnulib
   doesn't support AFAIK, except when the system codepage is UTF-8;
 . Emacs sometimes have special needs which require emulation of
   certain APIs in a way that is different from what Gnulib does
   (examples: getloadavg and ACL functions)

With the above in mind:

> I'd like to view this question from the process point-of-view:
> 
> If some new functionality test is introduced in gnulib/m4/printf.m4,
> be it
>   (a) because a bug has been discovered on a non-mingw platform
>       (such as recently the %lc bug), or

Not relevant to this discussion: non-MinGW platforms will get what
Gnulib provides.

>   (b) because a bug has been discovered on mingw, or

Depends whether this bug is relevant to Emacs, and whether the
relevant Gnulib functions are already used in Emacs on Windows.  If
the latter, we will simply use the updated Gnulib function.
Otherwise, it might need changes to Emacs's own code to work around or
fix the bug.

>   (c) because a new ISO C or POSIX standard requires new functionalities
>       (such as recently the support of %b),

If this is needed in Emacs, and in code that is used in the MinGW
build, we'd need to wait until __USE_MINGW_ANSI_STDIO will support the
new functionality, or provide some workaround in Emacs's code, or
declare that the relevant feature doesn't work in the MinGW build.  A
good example of this is the time-related functions in Emacs: we don't
support time-zone specifications of the form "Asia/Seoul" because the
Windows time-zone functionality cannot grok that.

> Will you typically want to
>   - review all format strings in Emacs, to see whether they are affected?
>   - add some note to Emacs-internal coding guidelines, e.g. to the effect
>     that %b should not be used?
>   - review the mingw-specific *printf override, to see whether it
>     needs a workaround (in case b) or an extension (in case c)?
>   - or do nothing at all?

Some mix of the above, depending on the case.  But only for the MinGW
build.

Btw, the problem with printf* is exacerbated because Gnulib pulls in
the entire stdio.h when it needs to replace some printf*
functionality, and stdio is a huge header/module with some functions
that we cannot allow to override in Emacs, due to the aspects I tried
to describe above.  Fortunately, Emacs needs printf* in only a handful
of places, and for very narrow functionality.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> > Will you typically want to
> >   - review all format strings in Emacs, to see whether they are affected?
> >   - add some note to Emacs-internal coding guidelines, e.g. to the effect
> >     that %b should not be used?
> >   - review the mingw-specific *printf override, to see whether it
> >     needs a workaround (in case b) or an extension (in case c)?
> >   - or do nothing at all?
> 
> Some mix of the above, depending on the case.  But only for the MinGW
> build.

OK. How do you reliably get notified about the relevant changes?
If you look at gnulib/ChangeLog and search for "mingw" or "Windows"
you will spot some of the relevant changes.

For more reliability, I would save the generated config.cache from a mingw
build somewhere, and compare the config.cache of newer builds with the
saved one. If you see an added gl_cv_* variable or an existing one
whose value has changed, you can raise your eyebrows. So, it makes
sense to override only the mimimum of gl_cv_* variables.

However, this approach would still have its potential gaps:
In case
> >   (b) because a bug has been discovered on mingw

Gnulib might stuff the new configure test into an existing AC_RUN_IFELSE
invocation and thus reuse an existing gl_cv_* variable. (Not for *printf,
but for other modules.) Say, gl_cv_foobar_works meant the absence of
bugs P and Q, and now it means the absence of bugs P, Q, and R. When
the override gl_cv_foobar_works=yes was added, it meant "our nt code
has workarounds for P and Q". Thus, you won't be alerted that you need
to add a workaround for R or remove the override gl_cv_foobar_works=yes.

If you were to build the corresponding gnulib tests as part of the Emacs
build (gnulib-tool option '--with-tests'), then we would have added a unit
test against bug R, and this test would fail, thus alerting you that
you need to do something.

Note: Since the gnulib-tool invocation includes many '--avoid' options,
some test failures are to be expected, until these tests are '--avoid'ed
as well.

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 17:46:27 +0200
> 
> Eli Zaretskii wrote:
> > > Will you typically want to
> > >   - review all format strings in Emacs, to see whether they are affected?
> > >   - add some note to Emacs-internal coding guidelines, e.g. to the effect
> > >     that %b should not be used?
> > >   - review the mingw-specific *printf override, to see whether it
> > >     needs a workaround (in case b) or an extension (in case c)?
> > >   - or do nothing at all?
> > 
> > Some mix of the above, depending on the case.  But only for the MinGW
> > build.
> 
> OK. How do you reliably get notified about the relevant changes?

By watching the Gnulib updates and new Gnulib modules that get
imported and compiled into libgnu.a.

> If you look at gnulib/ChangeLog and search for "mingw" or "Windows"
> you will spot some of the relevant changes.

Thanks for the pointer.

> For more reliability, I would save the generated config.cache from a mingw
> build somewhere, and compare the config.cache of newer builds with the
> saved one.

I do that as well, when I suspect some change could cause a
difference.

> In case
> > >   (b) because a bug has been discovered on mingw
> 
> Gnulib might stuff the new configure test into an existing AC_RUN_IFELSE
> invocation and thus reuse an existing gl_cv_* variable. (Not for *printf,
> but for other modules.) Say, gl_cv_foobar_works meant the absence of
> bugs P and Q, and now it means the absence of bugs P, Q, and R. When
> the override gl_cv_foobar_works=yes was added, it meant "our nt code
> has workarounds for P and Q". Thus, you won't be alerted that you need
> to add a workaround for R or remove the override gl_cv_foobar_works=yes.

The foobar function (or its emulation) needs to do its job on
MS-Windows well enough for us to set gl_cv_foobar_works=yes.  If it
doesn't, and Gnulib discovers that first (unlikely, but possible), we
will have to pick that up in some way, either by watching Gnulib
updates, or via user complaints, or in some other way.

Luckily, this happens very rarely, IME, at least as far as things
related to Emacs on Windows are concerned.

> If you were to build the corresponding gnulib tests as part of the Emacs
> build (gnulib-tool option '--with-tests'), then we would have added a unit
> test against bug R, and this test would fail, thus alerting you that
> you need to do something.

Emacs doesn't (yet) have a facility to run Gnulib tests.

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> > OK. How do you reliably get notified about the relevant changes?
> 
> By watching the Gnulib updates and new Gnulib modules that get
> imported and compiled into libgnu.a.
> ...
> > For more reliability, I would save the generated config.cache from a mingw
> > build somewhere, and compare the config.cache of newer builds with the
> > saved one.
> 
> I do that as well, when I suspect some change could cause a
> difference.
> ...
> Luckily, this happens very rarely, IME, at least as far as things
> related to Emacs on Windows are concerned.

OK, it sounds like this part of the interface between Gnulib and Emacs
development works well enough in practice? If you agree, then I'm glad
nothing needs to be changed on the Gnulib side in that respect.

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 20:54:43 +0200
> 
> Eli Zaretskii wrote:
> > > OK. How do you reliably get notified about the relevant changes?
> > 
> > By watching the Gnulib updates and new Gnulib modules that get
> > imported and compiled into libgnu.a.
> > ...
> > > For more reliability, I would save the generated config.cache from a mingw
> > > build somewhere, and compare the config.cache of newer builds with the
> > > saved one.
> > 
> > I do that as well, when I suspect some change could cause a
> > difference.
> > ...
> > Luckily, this happens very rarely, IME, at least as far as things
> > related to Emacs on Windows are concerned.
> 
> OK, it sounds like this part of the interface between Gnulib and Emacs
> development works well enough in practice? If you agree, then I'm glad
> nothing needs to be changed on the Gnulib side in that respect.

It works well enough, yes.  The number of times the build was broken
since we moved to using the Posix configury on Windows 10 years ago is
less than a dozen, I think.  Which is pretty fabulous, IMO.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: eggert@cs.ucla.edu,  bruno@clisp.org,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 18:10:32 +0800
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index 425eaace30d..f78ee525bf1 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -173,3 +173,21 @@ gl_cv_func_nanosleep=yes
>  # Suppress configure-time diagnostic from unnecessary libxattr check,
>  # as xattr will not be supported here.
>  enable_xattr=no
> +# Don't build gnulib printf either.
> +gl_cv_func_printf_sizes_c99=yes
> +gl_cv_func_printf_sizes_c23=yes
> +gl_cv_func_printf_long_double=yes
> +gl_cv_func_printf_infinite_long_double=yes
> +gl_cv_func_printf_directive_a=yes
> +gl_cv_func_printf_directive_b=yes
> +gl_cv_func_printf_directive_f=yes
> +gl_cv_func_printf_directive_n=yes
> +gl_cv_func_printf_directive_ls=yes
> +gl_cv_func_printf_directive_lc=yes
> +gl_cv_func_printf_positions=yes
> +gl_cv_func_printf_flag_grouping=yes
> +gl_cv_func_printf_flag_leftadjust=yes
> +gl_cv_func_printf_flag_zero=yes
> +gl_cv_func_printf_precision=yes
> +gl_cv_func_printf_enomem=yes
> +ac_cv_func_vasprintf=yes
> 
> Both the check for vasprintf (Gnulib eschews testing for asprintf, since
> asprintf is never present where vasprintf is not) and the checks for
> printf features are overridden, because Gnulib also tries to replace
> vasprintf if it discovers that the conventional printf functions will
> need to be replaced.

According to my reading of vasprintf.m4, if ac_cv_func_vasprintf=yes,
the rest of the tests, including adding asprintf to LIBOBJ, should not
have happened:

  AC_DEFUN([gl_FUNC_VASPRINTF],
  [
    AC_CHECK_FUNCS([vasprintf])
    if test $ac_cv_func_vasprintf = no; then  <<<<<<<<<<<<<<<<<<
      gl_REPLACE_VASPRINTF
    fi
  ])

Or, if we are using vasprintf-posix.m4 (are we?), then
gl_cv_func_vasprintf_posix should have done that:

  AC_DEFUN([gl_FUNC_VASPRINTF_POSIX],
  [
    AC_REQUIRE([gl_FUNC_VASPRINTF_IS_POSIX])
    if test $gl_cv_func_vasprintf_posix = no; then <<<<<<<<<<<<<<<<<<<
      gl_PREREQ_VASNPRINTF_WITH_POSIX_EXTRAS
      gl_REPLACE_VASNPRINTF
      gl_REPLACE_VASPRINTF
    fi
  ])

I see that gl_cv_func_vasprintf_posix is not in your patch to
mingw-cfg.site, so maybe adding that is all that's needed to avoid
overriding all the other gl_cv_func_printf_* variables?

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> According to my reading of vasprintf.m4, if ac_cv_func_vasprintf=yes,
> the rest of the tests, including adding asprintf to LIBOBJ, should not
> have happened:
> 
>   AC_DEFUN([gl_FUNC_VASPRINTF],
>   [
>     AC_CHECK_FUNCS([vasprintf])
>     if test $ac_cv_func_vasprintf = no; then  <<<<<<<<<<<<<<<<<<
>       gl_REPLACE_VASPRINTF
>     fi
>   ])

There are invocations of gl_REPLACE_VASPRINTF from other places as well.
This is why we couldn't turn the AC_LIBOBJ invocation into a lib_SOURCES
augmentation in the module description. (It would yield duplicate symbols
at link time, in some circumstances.)

Bruno

Re: Android port

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 15:12:21 +0200
> 
> Eli Zaretskii wrote:
> > According to my reading of vasprintf.m4, if ac_cv_func_vasprintf=yes,
> > the rest of the tests, including adding asprintf to LIBOBJ, should not
> > have happened:
> > 
> >   AC_DEFUN([gl_FUNC_VASPRINTF],
> >   [
> >     AC_CHECK_FUNCS([vasprintf])
> >     if test $ac_cv_func_vasprintf = no; then  <<<<<<<<<<<<<<<<<<
> >       gl_REPLACE_VASPRINTF
> >     fi
> >   ])
> 
> There are invocations of gl_REPLACE_VASPRINTF from other places as well.

Only 2 more, AFAICT, and we only care about those whose modules we
import.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Haible <bruno@clisp.org>
>> Cc: eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org
>> Date: Sun, 06 Aug 2023 15:12:21 +0200
>> 
>> Eli Zaretskii wrote:
>> > According to my reading of vasprintf.m4, if ac_cv_func_vasprintf=yes,
>> > the rest of the tests, including adding asprintf to LIBOBJ, should not
>> > have happened:
>> > 
>> >   AC_DEFUN([gl_FUNC_VASPRINTF],
>> >   [
>> >     AC_CHECK_FUNCS([vasprintf])
>> >     if test $ac_cv_func_vasprintf = no; then  <<<<<<<<<<<<<<<<<<
>> >       gl_REPLACE_VASPRINTF
>> >     fi
>> >   ])
>> 
>> There are invocations of gl_REPLACE_VASPRINTF from other places as well.
>
> Only 2 more, AFAICT, and we only care about those whose modules we
> import.

Hmm, yes.  Angelo, would you give this a spin and ack?

diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index f78ee525bf1..b6c7639362e 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -174,20 +174,5 @@ gl_cv_func_nanosleep=yes
 # as xattr will not be supported here.
 enable_xattr=no
 # Don't build gnulib printf either.
-gl_cv_func_printf_sizes_c99=yes
-gl_cv_func_printf_sizes_c23=yes
-gl_cv_func_printf_long_double=yes
-gl_cv_func_printf_infinite_long_double=yes
-gl_cv_func_printf_directive_a=yes
-gl_cv_func_printf_directive_b=yes
-gl_cv_func_printf_directive_f=yes
-gl_cv_func_printf_directive_n=yes
-gl_cv_func_printf_directive_ls=yes
-gl_cv_func_printf_directive_lc=yes
-gl_cv_func_printf_positions=yes
-gl_cv_func_printf_flag_grouping=yes
-gl_cv_func_printf_flag_leftadjust=yes
-gl_cv_func_printf_flag_zero=yes
-gl_cv_func_printf_precision=yes
-gl_cv_func_printf_enomem=yes
 ac_cv_func_vasprintf=yes
+gl_cv_func_vasprintf_posix=yes

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 15:41 CEST Po Lu ha scritto:
> [...]
> Hmm, yes.  Angelo, would you give this a spin and ack?
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index f78ee525bf1..b6c7639362e 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -174,20 +174,5 @@ gl_cv_func_nanosleep=yes
>  # as xattr will not be supported here.
>  enable_xattr=no
>  # Don't build gnulib printf either.
> -gl_cv_func_printf_sizes_c99=yes
> -gl_cv_func_printf_sizes_c23=yes
> -gl_cv_func_printf_long_double=yes
> -gl_cv_func_printf_infinite_long_double=yes
> -gl_cv_func_printf_directive_a=yes
> -gl_cv_func_printf_directive_b=yes
> -gl_cv_func_printf_directive_f=yes
> -gl_cv_func_printf_directive_n=yes
> -gl_cv_func_printf_directive_ls=yes
> -gl_cv_func_printf_directive_lc=yes
> -gl_cv_func_printf_positions=yes
> -gl_cv_func_printf_flag_grouping=yes
> -gl_cv_func_printf_flag_leftadjust=yes
> -gl_cv_func_printf_flag_zero=yes
> -gl_cv_func_printf_precision=yes
> -gl_cv_func_printf_enomem=yes
>  ac_cv_func_vasprintf=yes
> +gl_cv_func_vasprintf_posix=yes

On top of previous or from scratch? I tried from scratch and it faile to apply (bfbdf4eb892935536fc665d6cc986fd669364263 is the original source):

wget https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz

aunpack emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz

cd emacs-bfbdf4eb892935536fc665d6cc986fd669364263/

patch nt/mingw-cfg.site ../android-03.patch
patching file nt/mingw-cfg.site
Hunk #1 FAILED at 174.
1 out of 1 hunk FAILED -- saving rejects to file nt/mingw-cfg.site.rej

cat nt/mingw-cfg.site.rej
--- mingw-cfg.site
+++ mingw-cfg.site
@@ -174,20 +174,5 @@ gl_cv_func_nanosleep=yes
 # as xattr will not be supported here.
 enable_xattr=no
 # Don't build gnulib printf either.
-gl_cv_func_printf_sizes_c99=yes
-gl_cv_func_printf_sizes_c23=yes
-gl_cv_func_printf_long_double=yes
-gl_cv_func_printf_infinite_long_double=yes
-gl_cv_func_printf_directive_a=yes
-gl_cv_func_printf_directive_b=yes
-gl_cv_func_printf_directive_f=yes
-gl_cv_func_printf_directive_n=yes
-gl_cv_func_printf_directive_ls=yes
-gl_cv_func_printf_directive_lc=yes
-gl_cv_func_printf_positions=yes
-gl_cv_func_printf_flag_grouping=yes
-gl_cv_func_printf_flag_leftadjust=yes
-gl_cv_func_printf_flag_zero=yes
-gl_cv_func_printf_precision=yes
-gl_cv_func_printf_enomem=yes
 ac_cv_func_vasprintf=yes
+gl_cv_func_vasprintf_posix=yes

Re: Android port

[Angelo Graziosi]

Ah, on top applies! Testing wait..

> Il 06/08/2023 17:09 CEST Angelo Graziosi  ha scritto:

> On top of previous or from scratch?

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 17:35 CEST Angelo Graziosi ha scritto:
> 
>  
> Ah, on top applies! Testing wait..
> 
> > Il 06/08/2023 17:09 CEST Angelo Graziosi  ha scritto:
> 
> > On top of previous or from scratch?

Ok, the three patches (up today) apply cleanly but the build fails in the same manner..

...
  CC       acl_entries.o
  CC       asnprintf.o
  CC       asprintf.o
asprintf.c:30:1: error: redefinition of 'asprintf'
   30 | asprintf (char **resultp, const char *format, ...)
      | ^~~~~~~~
In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
                 from ../src/conf_post.h:38,
                 from ../src/config.h:3511,
                 from asprintf.c:18:
C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
  276 | int asprintf(char **__ret, const char *__format, ...)
      |     ^~~~~~~~
make[2]: *** [Makefile:102: asprintf.o] Error 1
make[2]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib»
make[1]: *** [Makefile:537: lib] Error 2
make[1]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
make[1]: ingresso nella directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
***
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
***   to further investigate the problem
***
make[1]: *** [Makefile:418: advice-on-failure] Error 2
make[1]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
make: *** [Makefile:374: all] Error 2

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 17:44:55 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: Bruno Haible <bruno@clisp.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > Il 06/08/2023 17:35 CEST Angelo Graziosi ha scritto:
> > 
> >  
> > Ah, on top applies! Testing wait..
> > 
> > > Il 06/08/2023 17:09 CEST Angelo Graziosi  ha scritto:
> > 
> > > On top of previous or from scratch?
> 
> Ok, the three patches (up today) apply cleanly but the build fails in the same manner..

Are you sure you did all the steps starting from autogen.sh and
running the configure script?

If yes, it means something else causes asnprintf.o to be added to
LIBOBJ.  What does the below show in the m4 directories (I think there
are two of them on the Android branch):

  $ grep 'gl_REPLACE_VASN\?PRINTF' *.m4

Thanks.

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 19:36 CEST Eli Zaretskii ha scritto:
> 
>  
> > Date: Sun, 6 Aug 2023 17:44:55 +0200 (CEST)
> > From: Angelo Graziosi 
> > Cc: Bruno Haible 
> > 
> > > Il 06/08/2023 17:35 CEST Angelo Graziosi ha scritto:
> > > 
> > >  
> > > Ah, on top applies! Testing wait..
> > > 
> > > > Il 06/08/2023 17:09 CEST Angelo Graziosi  ha scritto:
> > > 
> > > > On top of previous or from scratch?
> > 
> > Ok, the three patches (up today) apply cleanly but the build fails in the same manner..
> 
> Are you sure you did all the steps starting from autogen.sh and
> running the configure script?

For sanity check I removed the tree and repeated the steps:

$ aunpack emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz
$ cd emacs-bfbdf4eb892935536fc665d6cc986fd669364263/
$ patch nt/mingw-cfg.site ../android-01.patch
$ patch nt/mingw-cfg.site ../android-02.patch
$ patch nt/mingw-cfg.site ../android-03.patch

$ tail /tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/mingw-cfg.site
gl_cv_func_free_preserves_errno=yes
# Don't build the Gnulib nanosleep module: it requires W2K or later,
# and MinGW does have nanosleep.
gl_cv_func_nanosleep=yes
# Suppress configure-time diagnostic from unnecessary libxattr check,
# as xattr will not be supported here.
enable_xattr=no
# Don't build gnulib printf either.
ac_cv_func_vasprintf=yes
gl_cv_func_vasprintf_posix=yes


$ ./autogen.sh
$ ./configure
$ make
[...]
asprintf.c:30:1: error: redefinition of 'asprintf'
   30 | asprintf (char **resultp, const char *format, ...)
      | ^~~~~~~~
In file included from C:/msys64/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/inc/ms-w32.h:389,
                 from ../src/conf_post.h:38,
                 from ../src/config.h:3511,
                 from asprintf.c:18:
C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
  276 | int asprintf(char **__ret, const char *__format, ...)
      |     ^~~~~~~~
make[2]: *** [Makefile:102: asprintf.o] Error 1
make[2]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/lib»
make[1]: *** [Makefile:537: lib] Error 2
make[1]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
make[1]: ingresso nella directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
***
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
***   to further investigate the problem
***
make[1]: *** [Makefile:418: advice-on-failure] Error 2
make[1]: uscita dalla directory «/tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263»
make: *** [Makefile:374: all] Error 2

> 
> If yes, it means something else causes asnprintf.o to be added to
> LIBOBJ.  What does the below show in the m4 directories (I think there
> are two of them on the Android branch):
> 
>   $ grep 'gl_REPLACE_VASN\?PRINTF' *.m4

$ grep 'gl_REPLACE_VASN\?PRINTF' *.m4
printf-posix.m4:    gl_REPLACE_VASNPRINTF
vasnprintf.m4:    gl_REPLACE_VASNPRINTF
vasnprintf.m4:AC_DEFUN([gl_REPLACE_VASNPRINTF],
vasprintf.m4:    gl_REPLACE_VASPRINTF
vasprintf.m4:AC_DEFUN([gl_REPLACE_VASPRINTF],
vasprintf-posix.m4:    gl_REPLACE_VASNPRINTF
vasprintf-posix.m4:    gl_REPLACE_VASPRINTF
vfprintf-posix.m4:    gl_REPLACE_VASNPRINTF

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 20:11:05 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: luangruo@yahoo.com, bruno@clisp.org, eggert@cs.ucla.edu,
> 	emacs-devel@gnu.org
> 
> > Are you sure you did all the steps starting from autogen.sh and
> > running the configure script?
> 
> For sanity check I removed the tree and repeated the steps:
> 
> $ aunpack emacs-bfbdf4eb892935536fc665d6cc986fd669364263.tar.gz
> $ cd emacs-bfbdf4eb892935536fc665d6cc986fd669364263/
> $ patch nt/mingw-cfg.site ../android-01.patch
> $ patch nt/mingw-cfg.site ../android-02.patch
> $ patch nt/mingw-cfg.site ../android-03.patch
> 
> $ tail /tmp/emacs-bfbdf4eb892935536fc665d6cc986fd669364263/nt/mingw-cfg.site
> gl_cv_func_free_preserves_errno=yes
> # Don't build the Gnulib nanosleep module: it requires W2K or later,
> # and MinGW does have nanosleep.
> gl_cv_func_nanosleep=yes
> # Suppress configure-time diagnostic from unnecessary libxattr check,
> # as xattr will not be supported here.
> enable_xattr=no
> # Don't build gnulib printf either.
> ac_cv_func_vasprintf=yes
> gl_cv_func_vasprintf_posix=yes
> 
> 
> $ ./autogen.sh
> $ ./configure
> $ make
> [...]
> asprintf.c:30:1: error: redefinition of 'asprintf'
>    30 | asprintf (char **resultp, const char *format, ...)
>       | ^~~~~~~~

OK, thanks.

> >   $ grep 'gl_REPLACE_VASN\?PRINTF' *.m4
> 
> $ grep 'gl_REPLACE_VASN\?PRINTF' *.m4
> printf-posix.m4:    gl_REPLACE_VASNPRINTF
> vasnprintf.m4:    gl_REPLACE_VASNPRINTF
> vasnprintf.m4:AC_DEFUN([gl_REPLACE_VASNPRINTF],
> vasprintf.m4:    gl_REPLACE_VASPRINTF
> vasprintf.m4:AC_DEFUN([gl_REPLACE_VASPRINTF],
> vasprintf-posix.m4:    gl_REPLACE_VASNPRINTF
> vasprintf-posix.m4:    gl_REPLACE_VASPRINTF
> vfprintf-posix.m4:    gl_REPLACE_VASNPRINTF

So I think we need to set 3 more variables:

 gl_cv_func_printf_posix=yes
 gl_cv_func_vfprintf_posix=yes
 gl_cv_vasprintf_posix=yes

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 20:19 CEST Eli Zaretskii ha scritto:
> 
> So I think we need to set 3 more variables:
> 
>  gl_cv_func_printf_posix=yes
>  gl_cv_func_vfprintf_posix=yes
>  gl_cv_vasprintf_posix=yes

I did a quick try. Added manually the above lines to mingw-cfg.site file, reconfigured and 'make', but it fails as described..

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 20:34:55 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: luangruo@yahoo.com, bruno@clisp.org, eggert@cs.ucla.edu,
> 	emacs-devel@gnu.org
> 
> 
> > Il 06/08/2023 20:19 CEST Eli Zaretskii ha scritto:
> > 
> > So I think we need to set 3 more variables:
> > 
> >  gl_cv_func_printf_posix=yes
> >  gl_cv_func_vfprintf_posix=yes
> >  gl_cv_vasprintf_posix=yes
> 
> I did a quick try. Added manually the above lines to mingw-cfg.site file, reconfigured and 'make', but it fails as described..

Sorry, one typo and one more variable:

  gl_cv_func_printf_posix=yes
  gl_cv_func_vfprintf_posix=yes
  gl_cv_func_vasprintf_posix=yes
  ac_cv_func_vasnprintf

Thanks.

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 20:53 CEST Eli Zaretskii ha scritto:
> 
> Sorry, one typo and one more variable:
> 
>   gl_cv_func_printf_posix=yes
>   gl_cv_func_vfprintf_posix=yes
>   gl_cv_func_vasprintf_posix=yes
>   ac_cv_func_vasnprintf

Now:

$ tail nt/mingw-cfg.site
# Suppress configure-time diagnostic from unnecessary libxattr check,
# as xattr will not be supported here.
enable_xattr=no
# Don't build gnulib printf either.
ac_cv_func_vasprintf=yes
gl_cv_func_vasprintf_posix=yes
gl_cv_func_printf_posix=yes
gl_cv_func_vfprintf_posix=yes
gl_cv_func_vasprintf_posix=yes
ac_cv_func_vasnprintf


but I am afraid, it still fails...

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 22:26:20 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: luangruo@yahoo.com, bruno@clisp.org, eggert@cs.ucla.edu,
>  emacs-devel@gnu.org
> 
> 
> > Il 06/08/2023 20:53 CEST Eli Zaretskii ha scritto:
> > 
> > Sorry, one typo and one more variable:
> > 
> >   gl_cv_func_printf_posix=yes
> >   gl_cv_func_vfprintf_posix=yes
> >   gl_cv_func_vasprintf_posix=yes
> >   ac_cv_func_vasnprintf
> 
> Now:
> 
> $ tail nt/mingw-cfg.site
> # Suppress configure-time diagnostic from unnecessary libxattr check,
> # as xattr will not be supported here.
> enable_xattr=no
> # Don't build gnulib printf either.
> ac_cv_func_vasprintf=yes
> gl_cv_func_vasprintf_posix=yes
> gl_cv_func_printf_posix=yes
> gl_cv_func_vfprintf_posix=yes
> gl_cv_func_vasprintf_posix=yes
> ac_cv_func_vasnprintf
> 
> 
> but I am afraid, it still fails...

The last one should be

  ac_cv_func_vasnprintf=yes

Anyway, thank you for your efforts.

Re: Android port

[Angelo Graziosi]

> Il 07/08/2023 04:26 CEST Eli Zaretskii ha scritto:
> 
> 
> The last one should be
> 
>   ac_cv_func_vasnprintf=yes
> 
> Anyway, thank you for your efforts.

maybe we have to test master now. Right?

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> maybe we have to test master now. Right?

It works, since the printf module has been removed.

Re: Android port

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]

On Mon, Aug 7, 2023 at 2:22 AM Po Lu <luangruo@yahoo.com> wrote:
>
> Angelo Graziosi <angelo.g0@libero.it> writes:
>
> > maybe we have to test master now. Right?
>
> It works, since the printf module has been removed.
>

I'm not able to build the master branch starting from c71a52, here is
the relevant part of the log (attached), which starts with autogen &&
configure prior to the make, which failed:

  GEN      ../../etc/charsets/CP1258.map
  CC       indent.o
  CC       search.o
fileio.c: In function 'internal_delete_file':
fileio.c:2601:36: warning: passing argument 1 of
'internal_condition_case_2' from incompatible pointer type
[-Wincompatible-pointer-types]
 2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
      |                                    ^~~~~~~~~~~~~~~~~~~~~
      |                                    |
      |                                    struct Lisp_X * (*)(struct Lisp_X *)
In file included from fileio.c:49:
lisp.h:4582:47: note: expected 'struct Lisp_X * (*)(struct Lisp_X *,
struct Lisp_X *)' but argument is of type 'struct Lisp_X * (*)(struct
Lisp_X *)'
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
(Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
Lisp_Object (*) (Lisp_Object));
      |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fileio.c:2602:40: warning: passing argument 4 of
'internal_condition_case_2' from incompatible pointer type
[-Wincompatible-pointer-types]
 2602 |                                    Qt, internal_delete_file_1);
      |                                        ^~~~~~~~~~~~~~~~~~~~~~
      |                                        |
      |                                        struct Lisp_X *
(*)(struct Lisp_X *)
In file included from fileio.c:49:
lisp.h:4582:117: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'}
but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
(Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
Lisp_Object (*) (Lisp_Object));
      |
                                                     ^~~~~~~~~~~
fileio.c:2601:9: error: too few arguments to function
'internal_condition_case_2'
 2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from fileio.c:49:
lisp.h:4582:20: note: declared here
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
(Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
Lisp_Object (*) (Lisp_Object));
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
  GEN      ../../etc/charsets/CP10007.map
  CC       regex-emacs.o
  GEN      ../../etc/charsets/CP720.map
  GEN      ../../etc/charsets/CP858.map
  CC       undo.o
make[1]: *** [Makefile:455: fileio.o] Error 1
make[1]: *** Waiting for unfinished jobs....

Let me know if there's other information/digging I might provide.

Note, I updated my script to add V=1 for make in the future.

[-- Attachment #2: emacs-30-c71a52-make.log --]
[-- Type: application/octet-stream, Size: 62241 bytes --]

Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
Running 'autoreconf -fi' in exec ...
You can now run './configure'.
configure: loading site script /etc/config.site
checking for xcrun... no
checking for GNU Make... make
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
checking the compiler's target... x86_64-w64-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether the compiler is clang... no
checking for compiler option needed when checking for declarations... none
checking whether gcc and cc understand -c and -o together... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking for linux/fs.h... no
checking for malloc.h... yes
checking for sys/systeminfo.h... no
checking for sys/sysinfo.h... no
checking for coff.h... no
checking for pty.h... no
checking for sys/resource.h... yes
checking for sys/utsname.h... no
checking for pwd.h... yes
checking for utmp.h... no
checking for util.h... no
checking for sanitizer/lsan_interface.h... no
checking for sanitizer/asan_interface.h... no
checking for sanitizer/common_interface_defs.h... no
checking for sys/socket.h... yes
checking for sys/param.h... yes
checking for pthread.h... (cached) no
checking for malloc/malloc.h... no
checking for sys/un.h... no
checking for vfork.h... no
checking for dirent.h... yes
checking for execinfo.h... no
checking for linux/xattr.h... no
checking for stdio_ext.h... no
checking for sys/vfs.h... no
checking for sys/fs_types.h... no
checking for getopt.h... (cached) no
checking for sys/cdefs.h... yes
checking for sys/time.h... yes
checking for ieee754.h... no
checking for limits.h... yes
checking for sys/select.h... no
checking for stdbool.h... yes
checking for stdckdint.h... no
checking for sys/random.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking how to run the C preprocessor... gcc -I ./nt/inc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for Minix Amsterdam compiler... no
checking for ar... ar
checking for ranlib... ranlib
checking for gcc -I ./nt/inc option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for gcc -I ./nt/inc option for timestamps after 2038... none needed
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking whether the compiler is clang... no
checking whether C compiler handles -Werror -Wunknown-warning-option... no
checking whether -Wno-missing-field-initializers is needed... no
checking whether -Wuninitialized is supported... yes
checking whether C compiler handles -fstrict-flex-arrays... no
checking whether C compiler handles -Wall... yes
checking whether C compiler handles -Warith-conversion... yes
checking whether C compiler handles -Wdate-time... yes
checking whether C compiler handles -Wdisabled-optimization... yes
checking whether C compiler handles -Wdouble-promotion... yes
checking whether C compiler handles -Wduplicated-cond... yes
checking whether C compiler handles -Wextra... yes
checking whether C compiler handles -Wformat-signedness... yes
checking whether C compiler handles -Winit-self... yes
checking whether C compiler handles -Winvalid-pch... yes
checking whether C compiler handles -Wlogical-op... yes
checking whether C compiler handles -Wmissing-declarations... yes
checking whether C compiler handles -Wmissing-include-dirs... yes
checking whether C compiler handles -Wmissing-prototypes... yes
checking whether C compiler handles -Wnested-externs... yes
checking whether C compiler handles -Wnull-dereference... yes
checking whether C compiler handles -Wold-style-definition... yes
checking whether C compiler handles -Wopenmp-simd... yes
checking whether C compiler handles -Wpacked... yes
checking whether C compiler handles -Wpointer-arith... yes
checking whether C compiler handles -Wstrict-flex-arrays... no
checking whether C compiler handles -Wstrict-prototypes... yes
checking whether C compiler handles -Wsuggest-attribute=noreturn... yes
checking whether C compiler handles -Wsuggest-final-methods... yes
checking whether C compiler handles -Wsuggest-final-types... yes
checking whether C compiler handles -Wtrampolines... yes
checking whether C compiler handles -Wuninitialized... yes
checking whether C compiler handles -Wunknown-pragmas... yes
checking whether C compiler handles -Wunused-macros... yes
checking whether C compiler handles -Wvariadic-macros... yes
checking whether C compiler handles -Wvector-operation-performance... yes
checking whether C compiler handles -Wwrite-strings... yes
checking whether C compiler handles -Warray-bounds=2... yes
checking whether C compiler handles -Wattribute-alias=2... yes
checking whether C compiler handles -Wformat=2... yes
checking whether C compiler handles -Wformat-truncation=2... yes
checking whether C compiler handles -Wimplicit-fallthrough=5... yes
checking whether C compiler handles -Wshift-overflow=2... yes
checking whether C compiler handles -Wuse-after-free=3... no
checking whether C compiler handles -Wvla-larger-than=4031... yes
checking whether C compiler handles -Wredundant-decls... (cached) no
checking whether C compiler handles -Wno-missing-field-initializers... yes
checking whether C compiler handles -Wno-override-init... yes
checking whether C compiler handles -Wno-sign-compare... yes
checking whether C compiler handles -Wno-type-limits... yes
checking whether C compiler handles -Wno-unused-parameter... yes
checking whether C compiler handles -Wno-format-nonliteral... yes
checking whether C compiler handles -Wno-bidi-chars... no
checking whether C compiler handles -Wno-pointer-sign... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking command to symlink files in the same directory... /bin/ln
checking for install-info... /usr/bin/install-info
checking for gzip... /usr/bin/gzip
checking for 'find' args to delete a file... -delete
checking for brew... no
checking for -znocombreloc... not needed
checking whether addresses are sanitized... no
checking for math library... none required
checking for struct passwd.pw_gecos... yes
checking for pkg-config... /mingw64/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for machine/soundcard.h... no
checking for sys/soundcard.h... no
checking for soundcard.h... no
checking for mmsystem.h... yes
checking for _oss_ioctl in -lossaudio... no
checking for alsa >= 1.0.0... no
checking for ADDR_NO_RANDOMIZE... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for net/if.h... no
checking for ifaddrs.h... no
checking for net/if_dl.h... no
checking for struct ifreq.ifr_flags... no
checking for struct ifreq.ifr_hwaddr... no
checking for struct ifreq.ifr_netmask... no
checking for struct ifreq.ifr_broadaddr... no
checking for struct ifreq.ifr_addr... no
checking for struct ifreq.ifr_addr.sa_len... no
checking whether gcc understands -MMD -MF... yes
checking for gcc -I ./nt/inc options needed to detect all undeclared functions... none needed
checking for X... no
checking whether Windows API headers are recent enough... yes
checking for windres... windres
checking whether malloc is Doug Lea style... no
checking for sbrk... (cached) yes
checking for getpagesize... yes
checking for __lsan_ignore_object... no
checking for fork... no
checking for vfork... no
checking for fchmod... no
checking for canonicalize_file_name... (cached) yes
checking for realpath... (cached) yes
checking for lstat... (cached) yes
checking for fchmodat... (cached) yes
checking for lchmod... (cached) yes
checking for fcntl... (cached) yes
checking for fdopendir... (cached) not-needed
checking for listxattr... no
checking for fstatat... (cached) yes
checking for fsync... (cached) yes
checking for gettimeofday... yes
checking for memset_explicit... no
checking for memset_s... no
checking for pselect... (cached) yes
checking for pthread_sigmask... (cached) yes
checking for readlink... (cached) yes
checking for isblank... yes
checking for iswctype... yes
checking for strtoimax... yes
checking for symlink... (cached) yes
checking for localtime_r... no
checking for getdtablesize... no
checking for working mmap... no
checking for main in -lXbsd... no
checking for thread support... yes
checking for librsvg-2.0 >= 2.14.0... yes
checking for libwebpdemux >= 0.6.0... yes
checking for WebPGetInfo... yes
checking for sqlite3_open_v2 in -lsqlite3... yes
checking for sqlite3_load_extension in -lsqlite3... yes
checking for getaddrinfo_a in -lanl... no
checking for malloc_trim... no
checking for lgetfilecon in -lselinux... no
checking for gnutls >= 2.12.2... yes
checking for libsystemd >= 222... no
checking for jansson >= 2.7... yes
checking for tree-sitter >= 0.20.2... no
checking for tree-sitter >= 0.6.3... yes
checking for ts_set_allocator... yes
checking for windows.h... yes
checking for harfbuzz >= 1.2.3... yes
checking for hb_font_set_var_named_instance in -lharfbuzz... yes
checking for X11/xpm.h... yes
checking for jpeglib 6b or later... -ljpeg
checking for lcms2... yes
checking for library containing inflateEnd... -lz
checking for dladdr... no
checking for dlfunc... no
checking for gcc_jit_context_acquire in -lgccjit... yes
checking for libgccjit.h... yes
checking for png.h... yes
checking whether png_longjmp is declared... yes
checking for tiffio.h... yes
checking for gif_lib.h... yes
checking for gpm.h... no
checking for libxml-2.0 > 2.6.17... yes
checking for maillock in -lmail... no
checking for maillock in -llockfile... no
checking for liblockfile.so... no
checking for maillock.h... no
checking for linux/seccomp.h... no
checking for linux/filter.h... no
checking for libseccomp >= 2.5.2... no
checking size of long... 4
checking for accept4... no
checking for fchdir... no
checking for gethostname... (cached) yes
checking for getrusage... no
checking for get_current_dir_name... no
checking for lrand48... no
checking for random... (cached) yes
checking for rint... yes
checking for tcdrain... no
checking for trunc... yes
checking for select... (cached) yes
checking for getpagesize... (cached) yes
checking for setlocale... yes
checking for newlocale... no
checking for getrlimit... (cached) yes
checking for setrlimit... (cached) yes
checking for shutdown... (cached) yes
checking for pthread_sigmask... (cached) yes
checking for strsignal... (cached) no
checking for setitimer... (cached) yes
checking for sendto... (cached) yes
checking for recvfrom... (cached) yes
checking for getsockname... (cached) yes
checking for getifaddrs... no
checking for freeifaddrs... no
checking for gai_strerror... (cached) yes
checking for sync... no
checking for getpwent... no
checking for endpwent... no
checking for getgrent... no
checking for endgrent... no
checking for renameat2... no
checking for cfmakeraw... no
checking for cfsetspeed... no
checking for __executable_start... no
checking for log2... yes
checking for pthread_setname_np... yes
checking for pthread_set_name_np... no
checking whether cfmakeraw is inline... no
checking whether cfsetspeed is inline... no
checking whether pthread_setname_np takes a single argument... no
checking whether pthread_setname_np takes three arguments... no
checking for aligned_alloc... no
checking for posix_memalign... no
checking whether aligned_alloc is declared... no
checking for posix_madvise... no
checking for madvise... no
checking for __builtin_frame_address... yes
checking for __builtin_unwind_init... yes
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for grantpt... no
checking for getpt... no
checking for posix_openpt... no
checking for library containing tputs... none required
checking for timerfd interface... no
checking whether signals can be handled on alternate stack... no
checking for valgrind/valgrind.h... no
checking for struct unipair.unicode... no
checking for pid_t... yes
checking for snprintf... yes
checking for spawn.h... no
checking for posix_spawn... no
checking for posix_spawn_file_actions_addchdir... no
checking for posix_spawn_file_actions_addchdir_np... no
checking for posix_spawnattr_setflags... no
checking whether POSIX_SPAWN_SETSID is declared... no
checking whether GLib is linked in... no
checking for nl_langinfo and CODESET... (cached) yes
checking for nl_langinfo and _NL_PAPER_WIDTH... (cached) yes
checking for mbstate_t... yes
checking for _setjmp... no
checking for sigsetjmp... no
checking POSIX termios... no
checking for usable FIONREAD... yes
checking for usable SIGIO... no
checking for usable SIGPOLL... no
checking for struct alignment... yes
checking for C/C++ restrict keyword... __restrict__
checking for typeof syntax and keyword spelling... typeof
checking for statement expressions... yes
checking whether malloc (0) returns nonnull... yes
checking for sys/acl.h... yes
checking for library containing acl_get_file... (cached) none required
checking for acl_get_file... (cached) yes
checking for acl_get_fd... no
checking for acl_set_file... (cached) yes
checking for acl_set_fd... no
checking for acl_free... (cached) yes
checking for acl_from_mode... no
checking for acl_from_text... (cached) yes
checking for acl_delete_def_file... no
checking for acl_extended_file... no
checking for acl_delete_fd_np... no
checking for acl_delete_file_np... no
checking for acl_copy_ext_native... no
checking for acl_create_entry_np... no
checking for acl_to_short_text... no
checking for acl_free_text... no
checking for working acl_get_file... (cached) yes
checking for acl/libacl.h... no
checking for acl_entries... no
checking for ACL_FIRST_ENTRY... no
checking for ACL_TYPE_EXTENDED... no
checking for working alloca.h... no
checking for alloca... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking whether the preprocessor supports include_next... yes
checking whether source code line length is unlimited... yes
checking whether lstat correctly handles trailing slash... (cached) yes
checking whether // is distinct from /... yes
checking whether realpath works... (cached) yes
checking for faccessat... yes
checking whether byte ordering is bigendian... no
checking if environ is properly declared... yes
checking for complete errno.h... no
checking for EMULTIHOP value... no
checking for ENOLINK value... yes
checking for EOVERFLOW value... yes
checking whether ctype.h defines __header_inline... no
checking for mode_t... yes
checking whether strmode is declared... no
checking whether getline is declared... no
checking for gawk... gawk
checking for getopt.h... (cached) no
checking whether timespec_get is declared... no
checking for timespec_get... no
checking for struct timeval... yes
checking for wide-enough struct timeval.tv_sec member... (cached) yes
checking whether limits.h has WORD_BIT, BOOL_WIDTH etc.... no
checking whether the compiler produces multi-arch binaries... no
checking whether stdint.h conforms to C99... yes
checking whether stdint.h works without ISO C predefines... yes
checking whether stdint.h has UINTMAX_WIDTH etc.... no
checking for 64-bit off_t... yes
checking for 64-bit st_size... no
checking whether memmem is declared... no
checking whether memrchr is declared... no
checking whether <limits.h> defines MIN and MAX... no
checking whether <sys/param.h> defines MIN and MAX... no
checking whether time_t is signed... yes
checking whether alarm is declared... (cached) yes
checking for working mktime... (cached) yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... no
checking whether tzname is declared... yes
checking for tzname... yes
checking for struct tm.tm_gmtoff... no
checking whether <sys/select.h> is self-contained... no
checking for inline... inline
checking for sigset_t... no
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking for wchar_t... yes
checking for good max_align_t... yes
checking whether NULL can be used in arbitrary expressions... yes
checking for unreachable... no
checking whether fcloseall is declared... yes
checking whether getw is declared... yes
checking whether putw is declared... yes
checking which flavor of printf attribute matches inttypes macros... gnu
checking whether stpncpy is declared... no
checking whether strnlen is declared... yes
checking whether strtoimax is declared... yes
checking whether stat file-mode macros are broken... no
checking for nlink_t... no
checking for struct timespec in <time.h>... yes
checking for TIME_UTC in <time.h>... no
checking whether execvpe is declared... no
checking whether clearerr_unlocked is declared... no
checking whether feof_unlocked is declared... no
checking whether ferror_unlocked is declared... no
checking whether fflush_unlocked is declared... no
checking whether fgets_unlocked is declared... no
checking whether fputc_unlocked is declared... no
checking whether fputs_unlocked is declared... no
checking whether fread_unlocked is declared... no
checking whether fwrite_unlocked is declared... no
checking whether getc_unlocked is declared... no
checking whether getchar_unlocked is declared... no
checking whether putc_unlocked is declared... no
checking whether putchar_unlocked is declared... no
checking type of array argument to getgroups... int
checking whether getdelim is declared... no
checking whether getdtablesize is declared... no
checking whether malloc is ptrdiff_t safe... yes
checking whether malloc, realloc, calloc set errno on failure... no
checking for O_CLOEXEC... no
checking for promoted mode_t type... int
checking whether the utimes function works... no
checking for C compiler option to allow warnings... -Wno-error
checking for alignas and alignof... yes, <stdalign.h> macros
checking for static_assert... yes, an <assert.h> macro
checking for __builtin_expect... yes
checking for byteswap.h... no
checking for readlinkat... yes
checking for library containing clock_gettime... (cached) none required
checking for clock_getres... yes
checking for clock_gettime... (cached) no
checking for clock_settime... (cached) no
checking for copy_file_range... (cached) yes
checking for d_type member in directory struct... no
checking whether // is distinct from /... (cached) yes
checking whether dup2 works... (cached) yes
checking for faccessat... (cached) yes
checking whether fchmodat works... (cached) not-needed-so-yes
checking whether fcntl handles F_DUPFD correctly... (cached) yes
checking whether fcntl understands F_DUPFD_CLOEXEC... (cached) yes
checking whether fdopendir is declared... no
checking whether fdopendir works... (cached) no-but-not-needed-so-yes
checking for flexible array member... yes
checking for __fpending... no
checking whether free is known to preserve errno... (cached) yes
checking whether fstatat (..., 0) works... (cached) yes
checking for sys/mount.h... no
checking for statvfs function (SVR4)... no
checking for two-argument statfs with statfs.f_frsize member... no
checking for 3-argument statfs function (DEC OSF/1)... no
checking for two-argument statfs with statfs.f_bsize member (AIX, 4.3BSD)... no
checking for four-argument statfs (SVR3)... no
checking for two-argument statfs with statfs.f_fsize member (4.4BSD and NetBSD)... no
checking for futimens... not-needed
checking whether futimens works... (cached) not-needed-so-yes
checking for getline... no
checking for getloadavg... yes
checking for sys/loadavg.h... no
checking whether getloadavg is declared... no
checking for getrandom... no
checking for bcrypt.h... yes
checking whether the bcrypt library is guaranteed to be present... (cached) no
checking for gettimeofday with POSIX signature... yes
checking whether the compiler supports the __inline keyword... yes
checking for gmp.h... yes
checking for library containing __gmpz_roinit_n... -lgmp
checking for memmem... no
checking for mempcpy... yes
checking for memrchr... no
checking for explicit_memset... no
checking for mkostemp... no
checking for library containing nanosleep... none required
checking for working nanosleep... (cached) yes
checking for sys/pstat.h... no
checking for sys/sysmp.h... no
checking for sys/param.h... (cached) yes
checking for sys/sysctl.h... no
checking for sched_getaffinity_np... no
checking for pstat_getdynamic... no
checking for sysmp... no
checking for sysctl... no
checking for sched_getaffinity... no
checking for pipe2... yes
checking whether signature of pselect conforms to POSIX... (cached) yes
checking whether pselect detects invalid fds... (cached) yes
checking whether pthread_sigmask is a macro... (cached) no
checking whether pthread_sigmask works without -lpthread... yes
checking whether pthread_sigmask returns error numbers... (cached) yes
checking whether pthread_sigmask unblocks signals correctly... (cached) not relevant
checking whether readlink signature is correct... yes
checking whether readlink handles trailing slash correctly... (cached) yes
checking whether readlink truncates results correctly... (cached) yes
checking for readlinkat... (cached) yes
checking whether readlinkat signature is correct... yes
checking for working re_compile_pattern... no
checking for libintl.h... yes
checking whether isblank is declared... yes
checking for sig2str... no
checking for sigdescr_np... no
checking for socklen_t... yes
checking for ssize_t... yes
checking for struct stat.st_atim.tv_nsec... no
checking for struct stat.st_atimespec.tv_nsec... no
checking for struct stat.st_atimensec... no
checking for struct stat.st_atim.st__tim.tv_nsec... no
checking for struct stat.st_birthtimespec.tv_nsec... no
checking for struct stat.st_birthtimensec... no
checking for struct stat.st_birthtim.tv_nsec... no
checking for bool, true, false... no
checking for stpcpy... no
checking for stpncpy... no
checking for working strnlen... yes
checking whether strtoimax works... yes
checking whether symlink handles trailing slash correctly... (cached) yes
checking whether localtime_r is declared... no
checking whether localtime_r exists as an inline function... no
checking whether localtime works even near extrema... yes
checking for timezone_t... no
checking for timegm... no
checking whether timer_settime is declared... no
checking for utimensat... yes
checking whether utimensat works... (cached) yes
checking for variable-length arrays... yes
checking for getdelim... no
checking for flockfile... no
checking for funlockfile... no
checking whether getc_unlocked is declared... (cached) no
checking for __mktime_internal... no
checking for timer_getoverrun... no
checking for gcc  option to disable position independent executables... not needed
checking for __ctype_get_mb_cur_max... no
checking whether MB_CUR_MAX is defined to function that won't link... no

Configured for 'x86_64-w64-mingw32'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc  -O2 -DHAVE_CONFIG_H
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         yes
  What window system should Emacs use?                    w32
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                NONE
  Where do we find X Windows libraries?                   NONE
  Does Emacs use -lXaw3d?                                 no
  Is Emacs being built for Android?                       no 
  Does Emacs use the X Double Buffer Extension?           no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes 
  Does Emacs use a png library?                           yes 
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lwebp?                                  yes
  Does Emacs use -lsqlite3?                               yes
  Does Emacs use cairo?                                   no
  Does Emacs use -llcms2?                                 yes
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  yes (w32)
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use a file notification library?             yes (w32)
  Does Emacs use access control lists?                    yes
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              no
  Does Emacs use HarfBuzz?                                yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use -lsystemd?                               no
  Does Emacs use -ljansson?                               yes
  Does Emacs use -ltree-sitter?                           yes
  Does Emacs use the GMP library?                         yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   yes
  Does Emacs use version 2 of the X Input Extension?      no
  Does Emacs generate a smaller-size Japanese dictionary? no


configure: creating ./config.status
config.status: creating src/verbose.mk
config.status: creating nt/emacs.rc
config.status: creating nt/emacsclient.rc
config.status: creating src/emacs-module.h
config.status: creating Makefile
config.status: creating lib/gnulib.mk
config.status: creating ./doc/man/emacs.1
config.status: creating lib/Makefile
config.status: creating lib-src/Makefile
config.status: creating oldXMenu/Makefile
config.status: creating src/Makefile
config.status: creating lwlib/Makefile
config.status: creating nextstep/Makefile
config.status: creating nt/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating lisp/Makefile
config.status: creating leim/Makefile
config.status: creating test/Makefile
config.status: creating test/manual/noverlay/Makefile
config.status: creating test/infra/Makefile
config.status: creating admin/charsets/Makefile
config.status: creating admin/unidata/Makefile
config.status: creating admin/grammars/Makefile
config.status: creating java/Makefile
config.status: creating cross/Makefile
config.status: creating java/AndroidManifest.xml
config.status: creating src/config.h
config.status: linking lib/_Noreturn.h to cross/lib/_Noreturn.h
config.status: linking lib/acl-errno-valid.c to cross/lib/acl-errno-valid.c
config.status: linking lib/acl-internal.c to cross/lib/acl-internal.c
config.status: linking lib/acl-internal.h to cross/lib/acl-internal.h
config.status: linking lib/acl.h to cross/lib/acl.h
config.status: linking lib/acl_entries.c to cross/lib/acl_entries.c
config.status: linking lib/alloca.in.h to cross/lib/alloca.in.h
config.status: linking lib/allocator.c to cross/lib/allocator.c
config.status: linking lib/allocator.h to cross/lib/allocator.h
config.status: linking lib/arg-nonnull.h to cross/lib/arg-nonnull.h
config.status: linking lib/assert.in.h to cross/lib/assert.in.h
config.status: linking lib/at-func.c to cross/lib/at-func.c
config.status: linking lib/attribute.h to cross/lib/attribute.h
config.status: linking lib/binary-io.c to cross/lib/binary-io.c
config.status: linking lib/binary-io.h to cross/lib/binary-io.h
config.status: linking lib/byteswap.in.h to cross/lib/byteswap.in.h
config.status: linking lib/c++defs.h to cross/lib/c++defs.h
config.status: linking lib/c-ctype.c to cross/lib/c-ctype.c
config.status: linking lib/c-ctype.h to cross/lib/c-ctype.h
config.status: linking lib/c-strcase.h to cross/lib/c-strcase.h
config.status: linking lib/c-strcasecmp.c to cross/lib/c-strcasecmp.c
config.status: linking lib/c-strncasecmp.c to cross/lib/c-strncasecmp.c
config.status: linking lib/canonicalize-lgpl.c to cross/lib/canonicalize-lgpl.c
config.status: linking lib/careadlinkat.c to cross/lib/careadlinkat.c
config.status: linking lib/careadlinkat.h to cross/lib/careadlinkat.h
config.status: linking lib/cdefs.h to cross/lib/cdefs.h
config.status: linking lib/cloexec.c to cross/lib/cloexec.c
config.status: linking lib/cloexec.h to cross/lib/cloexec.h
config.status: linking lib/close-stream.c to cross/lib/close-stream.c
config.status: linking lib/close-stream.h to cross/lib/close-stream.h
config.status: linking lib/copy-file-range.c to cross/lib/copy-file-range.c
config.status: linking lib/count-leading-zeros.c to cross/lib/count-leading-zeros.c
config.status: linking lib/count-leading-zeros.h to cross/lib/count-leading-zeros.h
config.status: linking lib/count-one-bits.c to cross/lib/count-one-bits.c
config.status: linking lib/count-one-bits.h to cross/lib/count-one-bits.h
config.status: linking lib/count-trailing-zeros.c to cross/lib/count-trailing-zeros.c
config.status: linking lib/count-trailing-zeros.h to cross/lib/count-trailing-zeros.h
config.status: linking lib/diffseq.h to cross/lib/diffseq.h
config.status: linking lib/dirent-private.h to cross/lib/dirent-private.h
config.status: linking lib/dirent.in.h to cross/lib/dirent.in.h
config.status: linking lib/dirfd.c to cross/lib/dirfd.c
config.status: linking lib/dtoastr.c to cross/lib/dtoastr.c
config.status: linking lib/dtotimespec.c to cross/lib/dtotimespec.c
config.status: linking lib/dup2.c to cross/lib/dup2.c
config.status: linking lib/dynarray.h to cross/lib/dynarray.h
config.status: linking lib/eloop-threshold.h to cross/lib/eloop-threshold.h
config.status: linking lib/errno.in.h to cross/lib/errno.in.h
config.status: linking lib/euidaccess.c to cross/lib/euidaccess.c
config.status: linking lib/execinfo.c to cross/lib/execinfo.c
config.status: linking lib/execinfo.in.h to cross/lib/execinfo.in.h
config.status: linking lib/faccessat.c to cross/lib/faccessat.c
config.status: linking lib/fchmodat.c to cross/lib/fchmodat.c
config.status: linking lib/fcntl.c to cross/lib/fcntl.c
config.status: linking lib/fcntl.in.h to cross/lib/fcntl.in.h
config.status: linking lib/fdopendir.c to cross/lib/fdopendir.c
config.status: linking lib/file-has-acl.c to cross/lib/file-has-acl.c
config.status: linking lib/filemode.c to cross/lib/filemode.c
config.status: linking lib/filemode.h to cross/lib/filemode.h
config.status: linking lib/filename.h to cross/lib/filename.h
config.status: linking lib/filevercmp.c to cross/lib/filevercmp.c
config.status: linking lib/filevercmp.h to cross/lib/filevercmp.h
config.status: linking lib/flexmember.h to cross/lib/flexmember.h
config.status: linking lib/fpending.c to cross/lib/fpending.c
config.status: linking lib/fpending.h to cross/lib/fpending.h
config.status: linking lib/free.c to cross/lib/free.c
config.status: linking lib/fstatat.c to cross/lib/fstatat.c
config.status: linking lib/fsusage.c to cross/lib/fsusage.c
config.status: linking lib/fsusage.h to cross/lib/fsusage.h
config.status: linking lib/fsync.c to cross/lib/fsync.c
config.status: linking lib/ftoastr.c to cross/lib/ftoastr.c
config.status: linking lib/ftoastr.h to cross/lib/ftoastr.h
config.status: linking lib/futimens.c to cross/lib/futimens.c
config.status: linking lib/get-permissions.c to cross/lib/get-permissions.c
config.status: linking lib/getdelim.c to cross/lib/getdelim.c
config.status: linking lib/getdtablesize.c to cross/lib/getdtablesize.c
config.status: linking lib/getgroups.c to cross/lib/getgroups.c
config.status: linking lib/getline.c to cross/lib/getline.c
config.status: linking lib/getloadavg.c to cross/lib/getloadavg.c
config.status: linking lib/getopt-cdefs.in.h to cross/lib/getopt-cdefs.in.h
config.status: linking lib/getopt-core.h to cross/lib/getopt-core.h
config.status: linking lib/getopt-ext.h to cross/lib/getopt-ext.h
config.status: linking lib/getopt-pfx-core.h to cross/lib/getopt-pfx-core.h
config.status: linking lib/getopt-pfx-ext.h to cross/lib/getopt-pfx-ext.h
config.status: linking lib/getopt.c to cross/lib/getopt.c
config.status: linking lib/getopt.in.h to cross/lib/getopt.in.h
config.status: linking lib/getopt1.c to cross/lib/getopt1.c
config.status: linking lib/getopt_int.h to cross/lib/getopt_int.h
config.status: linking lib/getrandom.c to cross/lib/getrandom.c
config.status: linking lib/gettext.h to cross/lib/gettext.h
config.status: linking lib/gettime.c to cross/lib/gettime.c
config.status: linking lib/gettimeofday.c to cross/lib/gettimeofday.c
config.status: linking lib/group-member.c to cross/lib/group-member.c
config.status: linking lib/idx.h to cross/lib/idx.h
config.status: linking lib/ieee754.in.h to cross/lib/ieee754.in.h
config.status: linking lib/ignore-value.h to cross/lib/ignore-value.h
config.status: linking lib/intprops-internal.h to cross/lib/intprops-internal.h
config.status: linking lib/intprops.h to cross/lib/intprops.h
config.status: linking lib/inttypes.in.h to cross/lib/inttypes.in.h
config.status: linking lib/lchmod.c to cross/lib/lchmod.c
config.status: linking lib/libc-config.h to cross/lib/libc-config.h
config.status: linking lib/limits.in.h to cross/lib/limits.in.h
config.status: linking lib/lstat.c to cross/lib/lstat.c
config.status: linking lib/malloc.c to cross/lib/malloc.c
config.status: linking lib/malloc/dynarray-skeleton.c to cross/lib/malloc/dynarray-skeleton.c
config.status: linking lib/malloc/dynarray.h to cross/lib/malloc/dynarray.h
config.status: linking lib/malloc/dynarray_at_failure.c to cross/lib/malloc/dynarray_at_failure.c
config.status: linking lib/malloc/dynarray_emplace_enlarge.c to cross/lib/malloc/dynarray_emplace_enlarge.c
config.status: linking lib/malloc/dynarray_finalize.c to cross/lib/malloc/dynarray_finalize.c
config.status: linking lib/malloc/dynarray_resize.c to cross/lib/malloc/dynarray_resize.c
config.status: linking lib/malloc/dynarray_resize_clear.c to cross/lib/malloc/dynarray_resize_clear.c
config.status: linking lib/malloc/scratch_buffer.h to cross/lib/malloc/scratch_buffer.h
config.status: linking lib/malloc/scratch_buffer_grow.c to cross/lib/malloc/scratch_buffer_grow.c
config.status: linking lib/malloc/scratch_buffer_grow_preserve.c to cross/lib/malloc/scratch_buffer_grow_preserve.c
config.status: linking lib/malloc/scratch_buffer_set_array_size.c to cross/lib/malloc/scratch_buffer_set_array_size.c
config.status: linking lib/md5-stream.c to cross/lib/md5-stream.c
config.status: linking lib/md5.c to cross/lib/md5.c
config.status: linking lib/md5.h to cross/lib/md5.h
config.status: linking lib/memmem.c to cross/lib/memmem.c
config.status: linking lib/mempcpy.c to cross/lib/mempcpy.c
config.status: linking lib/memrchr.c to cross/lib/memrchr.c
config.status: linking lib/memset_explicit.c to cross/lib/memset_explicit.c
config.status: linking lib/mini-gmp-gnulib.c to cross/lib/mini-gmp-gnulib.c
config.status: linking lib/mini-gmp.c to cross/lib/mini-gmp.c
config.status: linking lib/mini-gmp.h to cross/lib/mini-gmp.h
config.status: linking lib/minmax.h to cross/lib/minmax.h
config.status: linking lib/mkostemp.c to cross/lib/mkostemp.c
config.status: linking lib/mktime-internal.h to cross/lib/mktime-internal.h
config.status: linking lib/mktime.c to cross/lib/mktime.c
config.status: linking lib/nanosleep.c to cross/lib/nanosleep.c
config.status: linking lib/nproc.c to cross/lib/nproc.c
config.status: linking lib/nproc.h to cross/lib/nproc.h
config.status: linking lib/nstrftime.c to cross/lib/nstrftime.c
config.status: linking lib/open.c to cross/lib/open.c
config.status: linking lib/openat-priv.h to cross/lib/openat-priv.h
config.status: linking lib/openat-proc.c to cross/lib/openat-proc.c
config.status: linking lib/openat.h to cross/lib/openat.h
config.status: linking lib/pathmax.h to cross/lib/pathmax.h
config.status: linking lib/pipe2.c to cross/lib/pipe2.c
config.status: linking lib/pselect.c to cross/lib/pselect.c
config.status: linking lib/pthread_sigmask.c to cross/lib/pthread_sigmask.c
config.status: linking lib/qcopy-acl.c to cross/lib/qcopy-acl.c
config.status: linking lib/rawmemchr.c to cross/lib/rawmemchr.c
config.status: linking lib/readlink.c to cross/lib/readlink.c
config.status: linking lib/readlinkat.c to cross/lib/readlinkat.c
config.status: linking lib/realloc.c to cross/lib/realloc.c
config.status: linking lib/regcomp.c to cross/lib/regcomp.c
config.status: linking lib/regex.c to cross/lib/regex.c
config.status: linking lib/regex.h to cross/lib/regex.h
config.status: linking lib/regex_internal.c to cross/lib/regex_internal.c
config.status: linking lib/regex_internal.h to cross/lib/regex_internal.h
config.status: linking lib/regexec.c to cross/lib/regexec.c
config.status: linking lib/root-uid.h to cross/lib/root-uid.h
config.status: linking lib/scratch_buffer.h to cross/lib/scratch_buffer.h
config.status: linking lib/set-permissions.c to cross/lib/set-permissions.c
config.status: linking lib/sha1.c to cross/lib/sha1.c
config.status: linking lib/sha1.h to cross/lib/sha1.h
config.status: linking lib/sha256.c to cross/lib/sha256.c
config.status: linking lib/sha256.h to cross/lib/sha256.h
config.status: linking lib/sha512.c to cross/lib/sha512.c
config.status: linking lib/sha512.h to cross/lib/sha512.h
config.status: linking lib/sig2str.c to cross/lib/sig2str.c
config.status: linking lib/sig2str.h to cross/lib/sig2str.h
config.status: linking lib/sigdescr_np.c to cross/lib/sigdescr_np.c
config.status: linking lib/signal.in.h to cross/lib/signal.in.h
config.status: linking lib/stat-time.c to cross/lib/stat-time.c
config.status: linking lib/stat-time.h to cross/lib/stat-time.h
config.status: linking lib/stdckdint.in.h to cross/lib/stdckdint.in.h
config.status: linking lib/stddef.in.h to cross/lib/stddef.in.h
config.status: linking lib/stdint.in.h to cross/lib/stdint.in.h
config.status: linking lib/stdio-impl.h to cross/lib/stdio-impl.h
config.status: linking lib/stdio.in.h to cross/lib/stdio.in.h
config.status: linking lib/stdlib.in.h to cross/lib/stdlib.in.h
config.status: linking lib/stpcpy.c to cross/lib/stpcpy.c
config.status: linking lib/stpncpy.c to cross/lib/stpncpy.c
config.status: linking lib/str-two-way.h to cross/lib/str-two-way.h
config.status: linking lib/strftime.h to cross/lib/strftime.h
config.status: linking lib/string.in.h to cross/lib/string.in.h
config.status: linking lib/strnlen.c to cross/lib/strnlen.c
config.status: linking lib/strtoimax.c to cross/lib/strtoimax.c
config.status: linking lib/strtol.c to cross/lib/strtol.c
config.status: linking lib/strtoll.c to cross/lib/strtoll.c
config.status: linking lib/symlink.c to cross/lib/symlink.c
config.status: linking lib/sys_random.in.h to cross/lib/sys_random.in.h
config.status: linking lib/sys_select.in.h to cross/lib/sys_select.in.h
config.status: linking lib/sys_stat.in.h to cross/lib/sys_stat.in.h
config.status: linking lib/sys_time.in.h to cross/lib/sys_time.in.h
config.status: linking lib/sys_types.in.h to cross/lib/sys_types.in.h
config.status: linking lib/tempname.c to cross/lib/tempname.c
config.status: linking lib/tempname.h to cross/lib/tempname.h
config.status: linking lib/time-internal.h to cross/lib/time-internal.h
config.status: linking lib/time.in.h to cross/lib/time.in.h
config.status: linking lib/time_r.c to cross/lib/time_r.c
config.status: linking lib/time_rz.c to cross/lib/time_rz.c
config.status: linking lib/timegm.c to cross/lib/timegm.c
config.status: linking lib/timespec-add.c to cross/lib/timespec-add.c
config.status: linking lib/timespec-sub.c to cross/lib/timespec-sub.c
config.status: linking lib/timespec.c to cross/lib/timespec.c
config.status: linking lib/timespec.h to cross/lib/timespec.h
config.status: linking lib/u64.c to cross/lib/u64.c
config.status: linking lib/u64.h to cross/lib/u64.h
config.status: linking lib/unistd.c to cross/lib/unistd.c
config.status: linking lib/unistd.in.h to cross/lib/unistd.in.h
config.status: linking lib/unlocked-io.h to cross/lib/unlocked-io.h
config.status: linking lib/utimens.c to cross/lib/utimens.c
config.status: linking lib/utimens.h to cross/lib/utimens.h
config.status: linking lib/utimensat.c to cross/lib/utimensat.c
config.status: linking lib/verify.h to cross/lib/verify.h
config.status: linking lib/vla.h to cross/lib/vla.h
config.status: linking lib/warn-on-use.h to cross/lib/warn-on-use.h
config.status: linking lib/xalloc-oversized.h to cross/lib/xalloc-oversized.h
config.status: linking lib/af_alg.h to cross/lib/af_alg.h
config.status: linking lib/save-cwd.h to cross/lib/save-cwd.h
config.status: linking lib/fingerprint.c to cross/lib/fingerprint.c
config.status: linking lib/fingerprint.h to cross/lib/fingerprint.h
config.status: linking lib/save-cwd.c to cross/lib/save-cwd.c
config.status: linking lib/openat-die.c to cross/lib/openat-die.c
config.status: linking lib/save-cwd.c to cross/lib/save-cwd.c
config.status: linking lib/min-max.h to cross/lib/min-max.h
config.status: executing src/epaths.h commands
config.status: executing src/.gdbinit commands
config.status: executing doc/emacs/emacsver.texi commands
config.status: executing etc-refcards-emacsver.tex commands
configure: WARNING: This configuration installs a 'movemail' program
that retrieves POP3 email via only insecure channels.
To omit insecure POP3, you can use './configure --without-pop'.
make -C lib all
make -C doc/lispref info
make -C doc/lispintro info
make -C doc/emacs info
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/doc/lispintro'
/usr/bin/mkdir -p ../../info
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/doc/lispref'
/usr/bin/mkdir -p ../../info
  GEN      info/dir
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/doc/emacs'
/usr/bin/mkdir -p ../../info
  GEN      ../../info/elisp.info
  GEN      ../../info/eintr.info
  GEN      ../../info/emacs.info
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/lib'
  GEN      alloca.h
  GEN      byteswap.h
  GEN      errno.h
  GEN      execinfo.humask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/share/man/man1"

  GEN      getopt.h
umask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/share/applications"
make -C nt install
  GEN      getopt-cdefs.h
thisdir=`pwd -P`; \
cd ./doc/man; \
for page in *.1; do \
  test "$page" = ChangeLog.1 && continue; \
  dest=`echo "${page}" | sed -e 's/\.1$//' -e 's,x,x,'`.1; \
  (cd "${thisdir}"; \
   /usr/bin/install -c -m 644 ./doc/man/${page} "/d/emacs-build/install/emacs-30-c71a52/share/man/man1/${dest}"); \
  [ -n "" ] || continue ; \
  rm -f "/d/emacs-build/install/emacs-30-c71a52/share/man/man1/${dest}.gz"; \
   -9n "/d/emacs-build/install/emacs-30-c71a52/share/man/man1/${dest}" || true; \
done
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
  RC       emacs.res
  GEN      malloc/dynarray.gl.h
tmp=etc/emacs.tmpdesktop; rm -f ${tmp}; \
sed -e "/^Exec=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  -e "/^Icon=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  -e "/^StartupNotify=true$/d" \
  ./etc/emacs.desktop > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/share/applications/`echo emacs | sed 's,x,x,'`.desktop"; \
rm -f ${tmp}
  CCLD     addpm.exe
  GEN      malloc/dynarray-skeleton.gl.h
  CCLD     cmdproxy.exe
  GEN      ieee754.h
  CCLD     ddeclient.exe
  GEN      limits.h
  GEN      stdckdint.h
  CCLD     runemacs.exe
  GEN      stddef.h
  GEN      stdint.h
  GEN      string.h
  GEN      sys/random.h
  GEN      time.h
tmp=etc/emacsclient.tmpdesktop; rm -f ${tmp}; \
client_name=`echo emacsclient | sed 's,x,x,'`.exe; \
sed -e "/^Exec=/ s|emacsclient|/d/emacs-build/install/emacs-30-c71a52/bin/${client_name}|" \
  -e "/^Icon=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  -e "/^StartupNotify=true$/d" \
  ./etc/emacsclient.desktop > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/share/applications/${client_name}.desktop"; \
rm -f ${tmp}
  CC       fingerprint.o
  CC       acl_entries.o
  CC       memmem.o
  CC       mktime.o
  CC       binary-io.o
  CC       c-ctype.o
  CC       c-strcasecmp.o
  CC       c-strncasecmp.o
  CC       close-stream.o
  CC       count-leading-zeros.o
  CC       count-one-bits.o
  CC       count-trailing-zeros.o
  CC       md5-stream.o
tmp=etc/emacs-mail.tmpdesktop; rm -f ${tmp}; \
sed -e "/^Exec=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  -e "/^Icon=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  ./etc/emacs-mail.desktop > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/share/applications/`echo emacs | sed 's,x,x,'`-mail.desktop"; \
rm -f ${tmp}
  CC       md5.o
  CC       sha1.o
  CC       sha256.o
  CC       sha512.o
  CC       dtoastr.o
  CC       dtotimespec.o
  CC       execinfo.o
  CC       filemode.o
  CC       filevercmp.o
  CC       fpending.o
  CC       getopt.o
  CC       getopt1.o
  CC       getrandom.o
  CC       gettime.o
  CC       gettimeofday.o
  CC       malloc/dynarray_at_failure.o
  CC       malloc/dynarray_emplace_enlarge.o
  CC       malloc/dynarray_finalize.o
tmp=etc/emacsclient-mail.tmpdesktop; rm -f ${tmp}; \
client_name=`echo emacsclient | sed 's,x,x,'`.exe; \
sed -e "/^Exec=/ s|emacsclient|/d/emacs-build/install/emacs-30-c71a52/bin/${client_name}|" \
  -e "/^Icon=emacs/ s/emacs/`echo emacs | sed 's,x,x,'`/" \
  ./etc/emacsclient-mail.desktop > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/share/applications/${client_name}-mail.desktop"; \
rm -f ${tmp}
  CC       malloc/dynarray_resize.o
  CC       malloc/dynarray_resize_clear.o
  CC       memrchr.o
  CC       memset_explicit.o
  CC       mkostemp.o
  CC       nstrftime.o
  CC       qcopy-acl.o
  CC       regex.o
  CC       sig2str.o
  CC       sigdescr_np.o
  CC       stat-time.o
  CC       stpcpy.o
  CC       tempname.o
  CC       time_r.o
umask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/share/metainfo"
tmp=etc/emacs.tmpmetainfo; rm -f ${tmp}; \
sed -e "s/emacs\.desktop/`echo emacs | sed 's,x,x,'`.desktop/" \
  ./etc/emacs.metainfo.xml > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/share/metainfo/`echo emacs | sed 's,x,x,'`.metainfo.xml"; \
rm -f ${tmp}
  CC       time_rz.o
  CC       timegm.o
  CC       timespec.o
  CC       timespec-add.o
  CC       timespec-sub.o
  CC       u64.o
umask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/lib/systemd/user"
tmp=etc/emacs.tmpservice; rm -f ${tmp}; \
client_name=`echo emacsclient | sed 's,x,x,'`.exe; \
sed -e '/^##/d' \
  -e "/^Documentation/ s/emacs(1)/`echo emacs | sed 's,x,x,'`(1)/" \
  -e "/^ExecStart/ s|emacs|/d/emacs-build/install/emacs-30-c71a52/bin/`echo emacs | sed 's,x,x,'`.exe|" \
  -e "/^ExecStop/ s|emacsclient|/d/emacs-build/install/emacs-30-c71a52/bin/${client_name}|" \
  ./etc/emacs.service > ${tmp}; \
/usr/bin/install -c -m 644 ${tmp} "/d/emacs-build/install/emacs-30-c71a52/lib/systemd/user/`echo emacs | sed 's,x,x,'`.service"; \
rm -f ${tmp}
thisdir=`pwd -P`; \
cd ./etc/images/icons || exit 1; umask 022 ; \
for dir in */*/apps */*/mimetypes; do \
  [ -d ${dir} ] || continue ; \
  ( cd "${thisdir}"; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/share/icons/${dir}" ) ; \
  for icon in ${dir}/emacs[.-]*; do \
    [ -r ${icon} ] || continue ; \
    ext=`echo "${icon}" | sed -e 's|.*\.||'`; \
    dest=`echo "${icon}" | sed -e 's|.*/||' -e "s|\\.${ext}\$||" -e 's/emacs/emacs/' -e 's,x,x,'`.${ext} ; \
    ( cd "${thisdir}"; \
      /usr/bin/install -c -m 644 ./etc/images/icons/${icon} "/d/emacs-build/install/emacs-30-c71a52/share/icons/${dir}/${dest}" ) \
    || exit 1; \
  done ; \
done

Installing utilities run internally by Emacs.
umask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/libexec/emacs/30.0.50/x86_64-w64-mingw32"
exp_archlibdir=`cd "/d/emacs-build/install/emacs-30-c71a52/libexec/emacs/30.0.50/x86_64-w64-mingw32" && pwd -P`; \
if [ "$exp_archlibdir" != "`pwd -P`" ]; then \
  for file in cmdproxy.exe ddeclient.exe; do \
    /usr/bin/install -c  $file "/d/emacs-build/install/emacs-30-c71a52/libexec/emacs/30.0.50/x86_64-w64-mingw32/$file" ; \
  done ; \
        fi

Installing utilities for users to run.
umask 022; /usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/bin"
for file in runemacs.exe addpm.exe ; do \
  /usr/bin/install -c  ${file} "/d/emacs-build/install/emacs-30-c71a52/bin"/`echo ${file} | sed -e 's/.exe$//' -e 's,x,x,'`.exe ; \
done
/usr/bin/mkdir -p "/d/emacs-build/install/emacs-30-c71a52/share/emacs/30.0.50"
/usr/bin/install -c -m 644 ./README.W32 "/d/emacs-build/install/emacs-30-c71a52/share/emacs/30.0.50"
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
  AR       libgnu.a
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/lib'
make -C nt all
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
make -C lib-src all
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/lib-src'
  CC       ntlib.o
  RC       emacsclient.res
  CC       pop.o
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/doc/lispintro'
  CCLD     etags.exe
  CCLD     ctags.exe
  CCLD     emacsclient.exe
  CCLD     emacsclientw.exe
  CCLD     ebrowse.exe
  CCLD     hexl.exe
  CCLD     movemail.exe
  CCLD     make-docfile.exe
  CCLD     make-fingerprint.exe
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/lib-src'
make -C src BIN_DESTDIR=''/d/emacs-build/install/emacs-30-c71a52/bin/'' \
	 ELN_DESTDIR='/d/emacs-build/install/emacs-30-c71a52/lib/emacs/30.0.50/' all
make[1]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/src'
  GEN      /c/users/corwi/emacs-build/git/emacs-30/src/lisp.mk
  GEN      globals.h
  GEN      buildobj.h
make -C ../nt ../src/emacs.res
make -C ../admin/charsets all
make -C ../admin/unidata charscript.el
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
  RC       ../src/emacs.res
make -C ../admin/unidata emoji-zwj.el
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/admin/unidata'
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
  GEN      ../../etc/charsets/8859-2.map
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/admin/unidata'
  GEN      ../../etc/charsets/8859-3.map
  GEN      ../../etc/charsets/8859-4.map
make -C ../admin/charsets cp51932.el
  GEN      ../../etc/charsets/8859-5.map
make -C ../admin/charsets eucjp-ms.el
  GEN      ../../etc/charsets/8859-6.map
  GEN      ../../etc/charsets/8859-7.map
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
  GEN      ../../etc/charsets/CP932-2BYTE.map
make[2]: Entering directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
  GEN      ../../lisp/international/eucjp-ms.el
  GEN      ../../etc/charsets/8859-8.map
  GEN      ../../etc/charsets/8859-9.map
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/nt'
  GEN      ../../lisp/international/charscript.el
  GEN      ../../lisp/international/emoji-zwj.el
  GEN      ../../etc/charsets/8859-10.map
  GEN      ../../etc/charsets/8859-11.map
  GEN      ../../etc/charsets/8859-13.map
  GEN      ../../etc/charsets/8859-14.map
  GEN      ../../etc/charsets/8859-15.map
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/admin/unidata'
  GEN      ../../etc/charsets/8859-16.map
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/admin/unidata'
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
  GEN      ../../etc/charsets/IBM037.map
  GEN      ../../etc/charsets/IBM038.map
  GEN      ../../etc/charsets/IBM256.map
  GEN      ../../etc/charsets/IBM273.map
  GEN      ../../etc/charsets/IBM274.map
  GEN      ../../etc/charsets/IBM275.map
  GEN      ../../lisp/international/cp51932.el
  GEN      ../../etc/charsets/IBM277.map
  GEN      ../../etc/charsets/IBM278.map
  GEN      ../../etc/charsets/IBM280.map
  GEN      ../../etc/charsets/IBM281.map
  GEN      ../../etc/charsets/IBM284.map
  GEN      ../../etc/charsets/IBM285.map
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
  GEN      ../../etc/charsets/IBM290.map
  GEN      ../../etc/charsets/IBM297.map
  GEN      ../../etc/charsets/IBM420.map
  GEN      ../../etc/charsets/IBM423.map
  GEN      ../../etc/charsets/IBM424.map
  GEN      ../../etc/charsets/IBM437.map
  GEN      ../../etc/charsets/IBM500.map
  GEN      ../../etc/charsets/IBM850.map
  GEN      ../../etc/charsets/IBM851.map
  GEN      ../../etc/charsets/IBM852.map
  GEN      ../../etc/charsets/IBM855.map
  GEN      ../../etc/charsets/IBM856.map
  CC       firstfile.o
  GEN      ../../etc/charsets/IBM857.map
  CC       dispnew.o
  GEN      ../../etc/charsets/IBM860.map
  CC       frame.o
  GEN      ../../etc/charsets/IBM861.map
  CC       scroll.o
  GEN      ../../etc/charsets/IBM862.map
  CC       xdisp.o
  GEN      ../../etc/charsets/IBM863.map
  CC       menu.o
  GEN      ../../etc/charsets/IBM864.map  CC       window.o

  GEN      ../../etc/charsets/IBM865.map
  GEN      ../../etc/charsets/IBM866.map
  CC       charset.o
  GEN      ../../etc/charsets/IBM868.map
  CC       coding.o
  GEN      ../../etc/charsets/IBM869.map
  GEN      ../../etc/charsets/IBM870.map
  CC       category.o
  GEN      ../../etc/charsets/IBM871.map
  CC       ccl.o
  CC       character.o
  GEN      ../../etc/charsets/IBM874.map
  CC       chartab.o
  GEN      ../../etc/charsets/IBM875.map
  CC       bidi.o
  CC       term.o
  CC       terminal.o
  GEN      ../../etc/charsets/IBM880.map
  CC       xfaces.o
  CC       emacs.o
  GEN      ../../etc/charsets/IBM891.map
  GEN      ../../etc/charsets/IBM903.map
  GEN      ../../etc/charsets/IBM904.map
  CC       keyboard.o
  CC       macros.o
  GEN      ../../etc/charsets/IBM905.map
  CC       keymap.o
  GEN      ../../etc/charsets/IBM918.map
  CC       sysdep.o
  GEN      ../../etc/charsets/IBM1004.map
  CC       bignum.o
  GEN      ../../etc/charsets/IBM1026.map
  CC       buffer.o
  GEN      ../../etc/charsets/IBM1047.map
  GEN      ../../etc/charsets/CP737.map
  GEN      ../../etc/charsets/CP775.map
  CC       filelock.o
  CC       insdel.o
  GEN      ../../etc/charsets/CP1125.map
  GEN      ../../etc/charsets/CP1250.map
  GEN      ../../etc/charsets/CP1251.map
  CC       marker.o
  GEN      ../../etc/charsets/CP1252.map
  GEN      ../../etc/charsets/CP1253.map
  CC       minibuf.o
  CC       fileio.o
  GEN      ../../etc/charsets/CP1254.map
  CC       dired.o
  GEN      ../../etc/charsets/CP1255.map
  CC       cmds.o
  GEN      ../../etc/charsets/CP1256.map
  CC       casetab.o
  GEN      ../../etc/charsets/CP1257.map
  CC       casefiddle.o
  GEN      ../../etc/charsets/CP1258.map
  CC       indent.o
  CC       search.o
fileio.c: In function 'internal_delete_file':
fileio.c:2601:36: warning: passing argument 1 of 'internal_condition_case_2' from incompatible pointer type [-Wincompatible-pointer-types]
 2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
      |                                    ^~~~~~~~~~~~~~~~~~~~~
      |                                    |
      |                                    struct Lisp_X * (*)(struct Lisp_X *)
In file included from fileio.c:49:
lisp.h:4582:47: note: expected 'struct Lisp_X * (*)(struct Lisp_X *, struct Lisp_X *)' but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
      |                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fileio.c:2602:40: warning: passing argument 4 of 'internal_condition_case_2' from incompatible pointer type [-Wincompatible-pointer-types]
 2602 |                                    Qt, internal_delete_file_1);
      |                                        ^~~~~~~~~~~~~~~~~~~~~~
      |                                        |
      |                                        struct Lisp_X * (*)(struct Lisp_X *)
In file included from fileio.c:49:
lisp.h:4582:117: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'} but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
      |                                                                                                                     ^~~~~~~~~~~
fileio.c:2601:9: error: too few arguments to function 'internal_condition_case_2'
 2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from fileio.c:49:
lisp.h:4582:20: note: declared here
 4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
  GEN      ../../etc/charsets/CP10007.map
  CC       regex-emacs.o
  GEN      ../../etc/charsets/CP720.map
  GEN      ../../etc/charsets/CP858.map
  CC       undo.o
make[1]: *** [Makefile:455: fileio.o] Error 1
make[1]: *** Waiting for unfinished jobs....
  GEN      ../../etc/charsets/GB2312.map
  GEN      ../../etc/charsets/GBK.map
  GEN      ../../etc/charsets/GB180302.map
  GEN      ../../etc/charsets/BIG5.map
  GEN      ../../etc/charsets/BIG5-HKSCS.map
  GEN      ../../etc/charsets/CNS-1.map
  GEN      ../../etc/charsets/CNS-2.map
  GEN      ../../etc/charsets/CNS-3.map
  GEN      ../../etc/charsets/CNS-4.map
  GEN      ../../etc/charsets/CNS-5.map
  GEN      ../../etc/charsets/CNS-6.map
  GEN      ../../etc/charsets/CNS-7.map
  GEN      ../../etc/charsets/CNS-F.map
  GEN      ../../etc/charsets/JISX0201.map
  GEN      ../../etc/charsets/JISX0208.map
  GEN      ../../etc/charsets/JISX0212.map
  GEN      ../../etc/charsets/JISX2132.map
  GEN      ../../etc/charsets/JISC6226.map
  GEN      ../../etc/charsets/JISX213A.map
  GEN      ../../etc/charsets/KSC5601.map
  GEN      ../../etc/charsets/KSC5636.map
  GEN      ../../etc/charsets/JOHAB.map
  GEN      ../../etc/charsets/KOI-8.map
  GEN      ../../etc/charsets/KOI8-R.map
  GEN      ../../etc/charsets/KOI8-U.map
  GEN      ../../etc/charsets/KOI8-T.map
  GEN      ../../etc/charsets/ALTERNATIVNYJ.map
  GEN      ../../etc/charsets/MIK.map
  GEN      ../../etc/charsets/PTCP154.map
  GEN      ../../etc/charsets/TIS-620.map
  GEN      ../../etc/charsets/VISCII.map
  GEN      ../../etc/charsets/VSCII.map
  GEN      ../../etc/charsets/VSCII-2.map
  GEN      ../../etc/charsets/KA-PS.map
  GEN      ../../etc/charsets/KA-ACADEMY.map
  GEN      ../../etc/charsets/HP-ROMAN8.map
  GEN      ../../etc/charsets/NEXTSTEP.map
  GEN      ../../etc/charsets/MACINTOSH.map
  GEN      ../../etc/charsets/EBCDICUK.map
  GEN      ../../etc/charsets/EBCDICUS.map
  GEN      ../../etc/charsets/stdenc.map
  GEN      ../../etc/charsets/symbol.map
  GEN      ../../etc/charsets/CP949-2BYTE.map
  GEN      ../../etc/charsets/BIG5-1.map
  GEN      ../../etc/charsets/BIG5-2.map
  GEN      ../../etc/charsets/MULE-ethiopic.map
  GEN      ../../etc/charsets/MULE-ipa.map
  GEN      ../../etc/charsets/MULE-is13194.map
  GEN      ../../etc/charsets/MULE-sisheng.map
  GEN      ../../etc/charsets/MULE-tibetan.map
  GEN      ../../etc/charsets/MULE-lviscii.map
  GEN      ../../etc/charsets/MULE-uviscii.map
  GEN      ../../etc/charsets/GB180304.map
  GEN      ../../etc/charsets/JISX2131.map
  GEN      charsets.stamp
make[2]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/admin/charsets'
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/doc/emacs'
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/src'
make: *** [Makefile:554: src] Error 2
make: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/c/users/corwi/emacs-build/git/emacs-30/doc/lispref'

Re: Android port

[Po Lu]

Corwin Brust <corwin@bru.st> writes:

> On Mon, Aug 7, 2023 at 2:22 AM Po Lu <luangruo@yahoo.com> wrote:
>>
>> Angelo Graziosi <angelo.g0@libero.it> writes:
>>
>> > maybe we have to test master now. Right?
>>
>> It works, since the printf module has been removed.
>>
>
> I'm not able to build the master branch starting from c71a52, here is
> the relevant part of the log (attached), which starts with autogen &&
> configure prior to the make, which failed:
>
>   GEN      ../../etc/charsets/CP1258.map
>   CC       indent.o
>   CC       search.o
> fileio.c: In function 'internal_delete_file':
> fileio.c:2601:36: warning: passing argument 1 of
> 'internal_condition_case_2' from incompatible pointer type
> [-Wincompatible-pointer-types]
>  2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
>       |                                    ^~~~~~~~~~~~~~~~~~~~~
>       |                                    |
>       |                                    struct Lisp_X * (*)(struct Lisp_X *)
> In file included from fileio.c:49:
> lisp.h:4582:47: note: expected 'struct Lisp_X * (*)(struct Lisp_X *,
> struct Lisp_X *)' but argument is of type 'struct Lisp_X * (*)(struct
> Lisp_X *)'
>  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object (*) (Lisp_Object));
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> fileio.c:2602:40: warning: passing argument 4 of
> 'internal_condition_case_2' from incompatible pointer type
> [-Wincompatible-pointer-types]
>  2602 |                                    Qt, internal_delete_file_1);
>       |                                        ^~~~~~~~~~~~~~~~~~~~~~
>       |                                        |
>       |                                        struct Lisp_X *
> (*)(struct Lisp_X *)
> In file included from fileio.c:49:
> lisp.h:4582:117: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'}
> but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
>  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object (*) (Lisp_Object));
>       |
>                                                      ^~~~~~~~~~~
> fileio.c:2601:9: error: too few arguments to function
> 'internal_condition_case_2'
>  2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from fileio.c:49:
> lisp.h:4582:20: note: declared here
>  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> Lisp_Object (*) (Lisp_Object));
>       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
>   GEN      ../../etc/charsets/CP10007.map
>   CC       regex-emacs.o
>   GEN      ../../etc/charsets/CP720.map
>   GEN      ../../etc/charsets/CP858.map
>   CC       undo.o
> make[1]: *** [Makefile:455: fileio.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
>
> Let me know if there's other information/digging I might provide.
>
> Note, I updated my script to add V=1 for make in the future.

I think this is a problem with the fileio stuff Eric installed earlier
instead of the Android port.  Simply one of the many hazards of
indiscriminately translating working C to Elisp...

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Angelo Graziosi <angelo.g0@libero.it>,  Eli Zaretskii <eliz@gnu.org>,
>   bruno@clisp.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Mon, 07 Aug 2023 16:44:46 +0800
> 
> Corwin Brust <corwin@bru.st> writes:
> 
> > On Mon, Aug 7, 2023 at 2:22 AM Po Lu <luangruo@yahoo.com> wrote:
> >>
> >> Angelo Graziosi <angelo.g0@libero.it> writes:
> >>
> >> > maybe we have to test master now. Right?
> >>
> >> It works, since the printf module has been removed.
> >>
> >
> > I'm not able to build the master branch starting from c71a52, here is
> > the relevant part of the log (attached), which starts with autogen &&
> > configure prior to the make, which failed:
> >
> >   GEN      ../../etc/charsets/CP1258.map
> >   CC       indent.o
> >   CC       search.o
> > fileio.c: In function 'internal_delete_file':
> > fileio.c:2601:36: warning: passing argument 1 of
> > 'internal_condition_case_2' from incompatible pointer type
> > [-Wincompatible-pointer-types]
> >  2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
> >       |                                    ^~~~~~~~~~~~~~~~~~~~~
> >       |                                    |
> >       |                                    struct Lisp_X * (*)(struct Lisp_X *)
> > In file included from fileio.c:49:
> > lisp.h:4582:47: note: expected 'struct Lisp_X * (*)(struct Lisp_X *,
> > struct Lisp_X *)' but argument is of type 'struct Lisp_X * (*)(struct
> > Lisp_X *)'
> >  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> > (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> > Lisp_Object (*) (Lisp_Object));
> >       |
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > fileio.c:2602:40: warning: passing argument 4 of
> > 'internal_condition_case_2' from incompatible pointer type
> > [-Wincompatible-pointer-types]
> >  2602 |                                    Qt, internal_delete_file_1);
> >       |                                        ^~~~~~~~~~~~~~~~~~~~~~
> >       |                                        |
> >       |                                        struct Lisp_X *
> > (*)(struct Lisp_X *)
> > In file included from fileio.c:49:
> > lisp.h:4582:117: note: expected 'Lisp_Object' {aka 'struct Lisp_X *'}
> > but argument is of type 'struct Lisp_X * (*)(struct Lisp_X *)'
> >  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> > (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> > Lisp_Object (*) (Lisp_Object));
> >       |
> >                                                      ^~~~~~~~~~~
> > fileio.c:2601:9: error: too few arguments to function
> > 'internal_condition_case_2'
> >  2601 |   tem = internal_condition_case_2 (Fdelete_file_internal, filename,
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from fileio.c:49:
> > lisp.h:4582:20: note: declared here
> >  4582 | extern Lisp_Object internal_condition_case_2 (Lisp_Object (*)
> > (Lisp_Object, Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object,
> > Lisp_Object (*) (Lisp_Object));
> >       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
> >   GEN      ../../etc/charsets/CP10007.map
> >   CC       regex-emacs.o
> >   GEN      ../../etc/charsets/CP720.map
> >   GEN      ../../etc/charsets/CP858.map
> >   CC       undo.o
> > make[1]: *** [Makefile:455: fileio.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> > Let me know if there's other information/digging I might provide.
> >
> > Note, I updated my script to add V=1 for make in the future.
> 
> I think this is a problem with the fileio stuff Eric installed earlier
> instead of the Android port.  Simply one of the many hazards of
> indiscriminately translating working C to Elisp...

Actually, it's partially my fault: I made a mistake in my fix of
Eric's changeset.  I hope it's fixed now on master.

Re: Android port

[Eli Zaretskii]

> Date: Mon, 7 Aug 2023 09:20:56 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: luangruo@yahoo.com, bruno@clisp.org, eggert@cs.ucla.edu,
> 	emacs-devel@gnu.org
> 
> 
> > Il 07/08/2023 04:26 CEST Eli Zaretskii ha scritto:
> > 
> > 
> > The last one should be
> > 
> >   ac_cv_func_vasnprintf=yes
> > 
> > Anyway, thank you for your efforts.
> 
> maybe we have to test master now. Right?

Right, thanks.

Re: Android port

[Angelo Graziosi]

> Il 07/08/2023 13:22 CEST Eli Zaretskii ha scritto:
> 
>  
> > Date: Mon, 7 Aug 2023 09:20:56 +0200 (CEST)
> > From: Angelo Graziosi <angelo.g0@libero.it>
> > Cc: luangruo@yahoo.com, bruno@clisp.org, eggert@cs.ucla.edu,
> > 	emacs-devel@gnu.org
> > 
> > 
> > > Il 07/08/2023 04:26 CEST Eli Zaretskii ha scritto:
> > > 
> > > 
> > > The last one should be
> > > 
> > >   ac_cv_func_vasnprintf=yes
> > > 
> > > Anyway, thank you for your efforts.
> > 
> > maybe we have to test master now. Right?
> 
> Right, thanks.

I have built master commit-7fb0248a33dc721ae570c294b04f6da94cd96b10 (20230807_130156) without issues..

Re: Android port

[Corwin Brust]

On Mon, Aug 7, 2023 at 7:03 AM Angelo Graziosi <angelo.g0@libero.it> wrote:
>
> I have built master commit-7fb0248a33dc721ae570c294b04f6da94cd96b10 (20230807_130156) without issues..
>

Me too (actually, I built the slightly newer a95253). Here are
installer and zips in case anyone else would like to try spotting
trouble:

  https://corwin.bru.st/emacs-30/emacs-30-a95253/

LGTM!

In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2023-08-07 built
 on AVALON
Repository revision: a95253f5cc1105619f6f93585dd41288f93384e4
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Home (v10.0.2009.19045.3271)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr comp comp-cstr warnings icons rx cl-seq cl-macs
gv cl-extra help-mode bytecomp byte-compile emacsbug message mailcap
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache
epa derived epg rfc6068 epg-config gnus-util text-property-search
time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win touch-screen tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 83477 11861) (symbols 48 7259 0) (strings 32 21655 2060)
 (string-bytes 1 636611) (vectors 16 16731)
 (vector-slots 8 340471 16814) (floats 8 30 63) (intervals 56 352 0)
 (buffers 992 12))

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 17:09:54 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: Bruno Haible <bruno@clisp.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> > Il 06/08/2023 15:41 CEST Po Lu ha scritto:
> > [...]
> > Hmm, yes.  Angelo, would you give this a spin and ack?
> > 
> > diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> > index f78ee525bf1..b6c7639362e 100644
> > --- a/nt/mingw-cfg.site
> > +++ b/nt/mingw-cfg.site
> > @@ -174,20 +174,5 @@ gl_cv_func_nanosleep=yes
> >  # as xattr will not be supported here.
> >  enable_xattr=no
> >  # Don't build gnulib printf either.
> > -gl_cv_func_printf_sizes_c99=yes
> > -gl_cv_func_printf_sizes_c23=yes
> > -gl_cv_func_printf_long_double=yes
> > -gl_cv_func_printf_infinite_long_double=yes
> > -gl_cv_func_printf_directive_a=yes
> > -gl_cv_func_printf_directive_b=yes
> > -gl_cv_func_printf_directive_f=yes
> > -gl_cv_func_printf_directive_n=yes
> > -gl_cv_func_printf_directive_ls=yes
> > -gl_cv_func_printf_directive_lc=yes
> > -gl_cv_func_printf_positions=yes
> > -gl_cv_func_printf_flag_grouping=yes
> > -gl_cv_func_printf_flag_leftadjust=yes
> > -gl_cv_func_printf_flag_zero=yes
> > -gl_cv_func_printf_precision=yes
> > -gl_cv_func_printf_enomem=yes
> >  ac_cv_func_vasprintf=yes
> > +gl_cv_func_vasprintf_posix=yes
> 
> On top of previous or from scratch?

On top of previous, I think.  In any case, you are supposed to be left
with just these two, under the "Don't build gnulib printf either"
comment:

  # Don't build gnulib printf either.
  ac_cv_func_vasprintf=yes
  gl_cv_func_vasprintf_posix=yes

Thanks.

Re: Android port

[Angelo Graziosi]

> Il 06/08/2023 17:39 CEST Eli Zaretskii ha scritto:
> 
>  

> On top of previous, I think.  In any case, you are supposed to be left
> with just these two, under the "Don't build gnulib printf either"
> comment:
> 
>   # Don't build gnulib printf either.
>   ac_cv_func_vasprintf=yes
>   gl_cv_func_vasprintf_posix=yes


Yes on top and nt/mingw-cfg.site has just that but, as I wrote few minutes ago, the build fails..

Re: Android port

[Bruno Haible]

Eli Zaretskii wrote:
> > And also %n (used in the rest of Emacs), which aborts on Android for
> > ``security'' reasons...
> 
> Most of those are not relevant for Android, right?
> 
> The only one which is relevant (in emacs.c) can be rewritten not to
> use %n.

Then I would suggest to rewrite this instance without %n.

Rationale: I cannot guarantee that Gnulib will be able to support %n
in the long run. The "security-aware community" are filing CVEs here and
there; %n is among their targets (it has already been disabled from libc
on Ubuntu, macOS, and MSVC); and I don't know when they will discover
that Gnulib still enables it.

Bruno

Re: Android port

[Manuel Giraud via Emacs development discussions.]

Bruno Haible <bruno@clisp.org> writes:

> Eli Zaretskii wrote:
>> > And also %n (used in the rest of Emacs), which aborts on Android for
>> > ``security'' reasons...
>> 
>> Most of those are not relevant for Android, right?
>> 
>> The only one which is relevant (in emacs.c) can be rewritten not to
>> use %n.
>
> Then I would suggest to rewrite this instance without %n.

There is a patch for this already in the OpenBSD ports tree:
https://cvsweb.openbsd.org/ports/editors/emacs/patches/patch-src_emacs_c?rev=1.5&content-type=text/x-cvsweb-markup
-- 
Manuel Giraud

Re: Android port

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
>   eggert@cs.ucla.edu,  angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 13:07:11 +0200
> 
> Bruno Haible <bruno@clisp.org> writes:
> 
> > Eli Zaretskii wrote:
> >> > And also %n (used in the rest of Emacs), which aborts on Android for
> >> > ``security'' reasons...
> >> 
> >> Most of those are not relevant for Android, right?
> >> 
> >> The only one which is relevant (in emacs.c) can be rewritten not to
> >> use %n.
> >
> > Then I would suggest to rewrite this instance without %n.
> 
> There is a patch for this already in the OpenBSD ports tree:
> https://cvsweb.openbsd.org/ports/editors/emacs/patches/patch-src_emacs_c?rev=1.5&content-type=text/x-cvsweb-markup

Thanks, but unless they contribute the code to us, pointing to that
code here is actually discouraged: it makes harder for people to write
an independent implementation that cannot be possibly taken as a copy
of theirs.

Rewriting this without %n is basically trivial.

Re: Android port

[Po Lu]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Bruno Haible <bruno@clisp.org> writes:
>
>> Eli Zaretskii wrote:
>>> > And also %n (used in the rest of Emacs), which aborts on Android for
>>> > ``security'' reasons...
>>> 
>>> Most of those are not relevant for Android, right?
>>> 
>>> The only one which is relevant (in emacs.c) can be rewritten not to
>>> use %n.
>>
>> Then I would suggest to rewrite this instance without %n.
>
> There is a patch for this already in the OpenBSD ports tree:
> https://cvsweb.openbsd.org/ports/editors/emacs/patches/patch-src_emacs_c?rev=1.5&content-type=text/x-cvsweb-markup

Please don't post these changes here, unless their authors have agreed
(and signed the paperwork) necessary to distribute them with Emacs!

Now that we can be construed to have read them, we must go out of our
way to make our code dissimilar, should we ever want to perform the same
modification.

Re: Android port

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On 2023-08-06 05:47, Po Lu wrote:
> Now that we can be construed to have read them, we must go out of our
> way to make our code dissimilar, should we ever want to perform the same
> modification.

I have not read those patches. I wrote the attached patch myself and 
installed it into the master branch, so we don't need to worry about 
printf %n for Android.

Although I don't know whether the attached patch is dissimilar to the 
OpenBSD patches that I haven't read, it's surely dissimilar emough, as 
the attached patch uses sprintf (safely) and the OpenBSD folks are 
allergic to sprintf.

[-- Attachment #2: 0001-Stop-using-printf-n.patch --]
[-- Type: text/x-patch, Size: 2210 bytes --]

From 1cc20535f8730f49cd5d012313c1eaf0627d7216 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 6 Aug 2023 09:08:56 -0700
Subject: [PATCH] Stop using printf %n
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/emacs.c (shut_down_emacs): Don’t use printf’s "%n" format.
Android, MS-Windows, and OpenBSD don’t support it, and it’s easy
enough to do its equivalent by hand.
---
 src/emacs.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/src/emacs.c b/src/emacs.c
index 80a013b68df..5a036554a87 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2959,24 +2959,31 @@ shut_down_emacs (int sig, Lisp_Object stuff)
       reset_all_sys_modes ();
       if (sig && sig != SIGTERM)
 	{
-	  static char const fmt[] = "Fatal error %d: %n%s\n";
 #ifdef HAVE_HAIKU
 	  if (haiku_debug_on_fatal_error)
 	    debugger ("Fatal error in Emacs");
 #endif
-	  char buf[max ((sizeof fmt - sizeof "%d%n%s\n"
+	  /* Output a "Fatal error NUM: DESC\n" diagnostic with a single write,
+	     but use multiple writes if the diagnosic is absurdly long
+	     and likely couldn't be written atomically anyway.  */
+	  static char const fmt[] = "Fatal error %d: ";
+	  char buf[max ((sizeof fmt - sizeof "%d"
 			 + INT_STRLEN_BOUND (int) + 1),
 			min (PIPE_BUF, MAX_ALLOCA))];
 	  char const *sig_desc = safe_strsignal (sig);
-	  int nlen;
-	  int buflen = snprintf (buf, sizeof buf, fmt, sig, &nlen, sig_desc);
-	  if (0 <= buflen && buflen < sizeof buf)
-	    emacs_write (STDERR_FILENO, buf, buflen);
+	  size_t sig_desclen = strlen (sig_desc);
+	  int nlen = sprintf (buf, fmt, sig);
+	  if (nlen + sig_desclen < sizeof buf - 1)
+	    {
+	      char *p = mempcpy (buf + nlen, sig_desc, sig_desclen);
+	      *p++ = '\n';
+	      emacs_write (STDERR_FILENO, buf, p - buf);
+	    }
 	  else
 	    {
 	      emacs_write (STDERR_FILENO, buf, nlen);
-	      emacs_write (STDERR_FILENO, sig_desc, strlen (sig_desc));
-	      emacs_write (STDERR_FILENO, fmt + sizeof fmt - 2, 1);
+	      emacs_write (STDERR_FILENO, sig_desc, sig_desclen);
+	      emacs_write (STDERR_FILENO, "\n", 1);
 	    }
 	}
     }
-- 
2.39.2

Re: Android port

[Po Lu]

Bruno Haible <bruno@clisp.org> writes:

> Rationale: I cannot guarantee that Gnulib will be able to support %n
> in the long run. The "security-aware community" are filing CVEs here and
> there; %n is among their targets (it has already been disabled from libc
> on Ubuntu, macOS, and MSVC); and I don't know when they will discover
> that Gnulib still enables it.

Then Gnulib should disregard their whims and move on.  If a program
employs %n incorrectly, and that exposes a security vulnerability as a
result, the fault lies with the authors of said program rather than
Gnulib.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  eggert@cs.ucla.edu,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 20:16:14 +0800
> 
> Bruno Haible <bruno@clisp.org> writes:
> 
> > Rationale: I cannot guarantee that Gnulib will be able to support %n
> > in the long run. The "security-aware community" are filing CVEs here and
> > there; %n is among their targets (it has already been disabled from libc
> > on Ubuntu, macOS, and MSVC); and I don't know when they will discover
> > that Gnulib still enables it.
> 
> Then Gnulib should disregard their whims and move on.

I think what Bruno tells us is that removing %n where it is not
strictly needed is a good way of eliminating the cause for both
problems.  We may not agree with CVEs against %n, but we won't keep %n
just because we disagree, right?

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]


Po Lu <luangruo@yahoo.com> writes:

> And also %n (used in the rest of Emacs), which aborts on Android for
> ``security'' reasons...

No need for the air-quotes, it is quite justified (and could probably be
backed up more empirically if someone went over something like the
Debian code-search).

In my many years of writing and reading C on all levels, I've seen %n
used outside of arbitrary memory write exploits at most a handful of
times.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Eli Zaretskii <eliz@gnu.org>,
>  bruno@clisp.org, angelo.g0@libero.it, emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 11:39:16 +0200
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > And also %n (used in the rest of Emacs), which aborts on Android for
> > ``security'' reasons...
> 
> No need for the air-quotes, it is quite justified (and could probably be
> backed up more empirically if someone went over something like the
> Debian code-search).
> 
> In my many years of writing and reading C on all levels, I've seen %n
> used outside of arbitrary memory write exploits at most a handful of
> times.

Thank you for your input, but please keep irrelevant tangents out of
this discussion.  We want to merge the Android branch as soon as
possible, and converting this into yet another futile dispute about
security will get in the way of finding the best solutions.

Re: Android port

[Bruno Haible]

Paul Eggert wrote:
> As I understand it the Android port uses Gnulib printf-posix and 
> vasprintf-posix modules only because Android printf lacks support for 
> "%td", "%jd" and "%ju".

No, that's not the case. Android *printf supports the 't', 'j', 'z' already
since 2009-03-04 (ca. Android 1.6).

I don't know what's the minimum supported Android version targetted by Po Lu
is, but for Android 4.3 you find the deficiencies listed in gnulib/m4/printf.m4:

dnl . = yes, # = no.
dnl
dnl                                  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
dnl   Android 4.3                    .  #  .  #  #  #  #  #  #  #  #  ?  .  #  .  #  .  #  .  .  .  #  .  .

Legend:
dnl 2 = checking whether printf supports size specifiers as in C23...
dnl 4 = checking whether printf supports infinite 'double' arguments...
dnl 5 = checking whether printf supports infinite 'long double' arguments...
dnl 6 = checking whether printf supports the 'a' and 'A' directives...
dnl 7 = checking whether printf supports the 'b' directive...
dnl 8 = checking whether printf supports the 'B' directive...
dnl 9 = checking whether printf supports the 'F' directive...
dnl 10 = checking whether printf supports the 'n' directive...
dnl 11 = checking whether printf supports the 'ls' directive...
dnl 12 = checking whether printf supports the 'lc' directive correctly...
dnl 14 = checking whether printf supports the grouping flag...
dnl 16 = checking whether printf supports the zero flag correctly...
dnl 18 = checking whether printf survives out-of-memory conditions...
dnl 22 = checking whether snprintf fully supports the 'n' directive...

> If this understanding is correct, how about if 
> we go through the printf formats in the Emacs C source code, and replace 
> all uses of "%jd" and "%ju" with "%"PRIdMAX and "%"PRIuMAX, and all uses 
> of "%td" with "%"pT"d" where pT is an Emacs invention defined like this:
> 
>   #ifdef __ANDROID__
>   # define pT "z"
>   #else
>   # define pT "t"
>   #endif

This workaround is not needed, since the problem is not there, not for
Android and not for other platforms either: Gnulib's documentation lists
the platforms

  @item
  This function does not support size specifiers as in C99 (@code{hh}, @code{ll},
  @code{j}, @code{t}, @code{z}) on some platforms:
  AIX 5.1, HP-UX 11.23, IRIX 6.5, Solaris 9, Cygwin 1.5.24, mingw, MSVC 14.

AIX 5.1, HP-UX 11.23, IRIX 6.5, Solaris 9, Cygwin 1.5.24 are long obsolete,
mingw is dealt with by Emacs differently, and MSVC is not supported by
Emacs (AFAIU).

Bruno

Re: Android port

[Po Lu]

Bruno Haible <bruno@clisp.org> writes:

> Paul Eggert wrote:
>> As I understand it the Android port uses Gnulib printf-posix and 
>> vasprintf-posix modules only because Android printf lacks support for 
>> "%td", "%jd" and "%ju".
>
> No, that's not the case. Android *printf supports the 't', 'j', 'z' already
> since 2009-03-04 (ca. Android 1.6).
>
> I don't know what's the minimum supported Android version targetted by Po Lu

Android 2.2.

That being said, I'm reluctant to remove the printf-posix module at this
stage of the port's development.  Emacs has undergone extensive testing
on all supported versions of Android with the Gnulib printf, and hardly
any at all without.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Paul Eggert <eggert@cs.ucla.edu>,
>  angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 20:20:20 +0800
> 
> That being said, I'm reluctant to remove the printf-posix module at this
> stage of the port's development.  Emacs has undergone extensive testing
> on all supported versions of Android with the Gnulib printf, and hardly
> any at all without.

Is there a way of running specific Gnulib tests only on some
platforms (without setting the gl_cv_* variables)?

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is there a way of running specific Gnulib tests only on some
> platforms (without setting the gl_cv_* variables)?

I don't think we can with this module.

Re: Android port

[Bruno Haible]

Po Lu wrote:
> > That being said, I'm reluctant to remove the printf-posix module at this
> > stage of the port's development.  Emacs has undergone extensive testing
> > on all supported versions of Android with the Gnulib printf, and hardly
> > any at all without.

In other words, you want to use the printf-posix module on Android but
not on mingw.

Eli Zaretskii wrote:
> Is there a way of running specific Gnulib tests only on some
> platforms (without setting the gl_cv_* variables)?

Your question makes me think of a way to use a module on one platform
but not on another platform. Namely, the Emacs' invocation of gnulib-tool
already contains --conditional-dependencies (see emacs/lib/gnulib.mk.in).
Combine this with the feature explained in
https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html

1) Add a file emacs/gnulib-local/modules/printf-for-emacs with the following
   contents:

=========================================================================
Description:
POSIX compatible printf() function on selected platforms.

Depends-on:
printf-posix     [case "$host_os" in mingw*) false;; *) true;; esac]
=========================================================================

   What this does is to add a module with a conditional dependency to
   'printf-posix'.

2) In the gnulib-tool invocation, add the option --local-dir=../gnulib-local
   (so that it references the emacs/gnulib-local/ directory), and add
   the module 'printf-for-emacs' to the module list.

I believe this solution will work unchanged for 10 or 20 years.

Bruno

Re: Android port

[Po Lu]

Bruno Haible <bruno@clisp.org> writes:

> In other words, you want to use the printf-posix module on Android but
> not on mingw.

Yes.

> Your question makes me think of a way to use a module on one platform
> but not on another platform. Namely, the Emacs' invocation of gnulib-tool
> already contains --conditional-dependencies (see emacs/lib/gnulib.mk.in).
> Combine this with the feature explained in
> https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html
>
> 1) Add a file emacs/gnulib-local/modules/printf-for-emacs with the following
>    contents:
>
> =========================================================================
> Description:
> POSIX compatible printf() function on selected platforms.
>
> Depends-on:
> printf-posix     [case "$host_os" in mingw*) false;; *) true;; esac]
> =========================================================================
>
>    What this does is to add a module with a conditional dependency to
>    'printf-posix'.
>
> 2) In the gnulib-tool invocation, add the option --local-dir=../gnulib-local
>    (so that it references the emacs/gnulib-local/ directory), and add
>    the module 'printf-for-emacs' to the module list.
>
> I believe this solution will work unchanged for 10 or 20 years.

Eli, are you OK with this solution?

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  eggert@cs.ucla.edu,  angelo.g0@libero.it,
>   emacs-devel@gnu.org
> Date: Sun, 06 Aug 2023 20:51:40 +0800
> 
> Bruno Haible <bruno@clisp.org> writes:
> 
> > 1) Add a file emacs/gnulib-local/modules/printf-for-emacs with the following
> >    contents:
> >
> > =========================================================================
> > Description:
> > POSIX compatible printf() function on selected platforms.
> >
> > Depends-on:
> > printf-posix     [case "$host_os" in mingw*) false;; *) true;; esac]
> > =========================================================================
> >
> >    What this does is to add a module with a conditional dependency to
> >    'printf-posix'.
> >
> > 2) In the gnulib-tool invocation, add the option --local-dir=../gnulib-local
> >    (so that it references the emacs/gnulib-local/ directory), and add
> >    the module 'printf-for-emacs' to the module list.
> >
> > I believe this solution will work unchanged for 10 or 20 years.
> 
> Eli, are you OK with this solution?

Yes (assuming it works: that remains to be seen).  But: (a) I'd like
to hear Paul's opinion on this solution, since he is the one who
routinely imports Gnulib into Emacs; and (b) I'd like to see if
setting gl_cv_func_vasprintf_posix=yes in mingw-cfg.site (in addition
to ac_cv_func_vasprintf, if needed) will disable the compilation of
the *printf modules and solve the problem in a way that is simple and
doesn't require introduction of any new infrastructure into Emacs.

Re: Android port

[Bruno Haible]

I wrote:
> already contains --conditional-dependencies (see emacs/lib/gnulib.mk.in).
> Combine this with the feature explained in
> https://www.gnu.org/software/gnulib/manual/html_node/Extending-Gnulib.html

PS: The differences between this approach and the OMIT_GNULIB_MODULE_*
approach (as far as I understand it) are:

* This approach uses only documented Gnulib features.
  Whereas the OMIT_GNULIB_MODULE_* approach hacks generated files and
  is thus more fragile.

* This approach has an effect on both the set of .m4 code executed by
  configure _and_ the generated Makefiles.
  Whereas the OMIT_GNULIB_MODULE_* approach does not change what happens
  at configure time, it only modifies the generated Makefiles.

Paul, please correct me if that is not correct?

Bruno

Re: Android port

[Paul Eggert]

On 2023-08-06 06:07, Bruno Haible wrote:
> PS: The differences between this approach and the OMIT_GNULIB_MODULE_*
> approach (as far as I understand it) are:
> 
> * This approach uses only documented Gnulib features.
>    Whereas the OMIT_GNULIB_MODULE_* approach hacks generated files and
>    is thus more fragile.
> 
> * This approach has an effect on both the set of .m4 code executed by
>    configure_and_  the generated Makefiles.
>    Whereas the OMIT_GNULIB_MODULE_* approach does not change what happens
>    at configure time, it only modifies the generated Makefiles.

Thanks, Bruno, this sounds like a promising idea. I'll add it to my list 
of things to do for Emacs. I'm hoping that it isn't needed for merging 
the Android port, though, as it'll require some thinking and testing of 
its own.

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 11:10:29 -0700
> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>,
>  angelo.g0@libero.it, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2023-08-06 06:07, Bruno Haible wrote:
> > PS: The differences between this approach and the OMIT_GNULIB_MODULE_*
> > approach (as far as I understand it) are:
> > 
> > * This approach uses only documented Gnulib features.
> >    Whereas the OMIT_GNULIB_MODULE_* approach hacks generated files and
> >    is thus more fragile.
> > 
> > * This approach has an effect on both the set of .m4 code executed by
> >    configure_and_  the generated Makefiles.
> >    Whereas the OMIT_GNULIB_MODULE_* approach does not change what happens
> >    at configure time, it only modifies the generated Makefiles.
> 
> Thanks, Bruno, this sounds like a promising idea. I'll add it to my list 
> of things to do for Emacs. I'm hoping that it isn't needed for merging 
> the Android port, though, as it'll require some thinking and testing of 
> its own.

I agree: this is certainly something to consider for the future, but
it is better kept separate from the prerequisites for merging the
Android branch.  The main "beneficiary" of migrating to this method is
the MinGW build (and the Gnulib import job), not the Android build.

Re: Android port

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

On 2023-08-06 05:20, Po Lu wrote:
> That being said, I'm reluctant to remove the printf-posix module at this
> stage of the port's development.  Emacs has undergone extensive testing
> on all supported versions of Android with the Gnulib printf, and hardly
> any at all without.

I understand the reluctance from the Android point of view. However, 
printf-posix imports 69 new source files to Emacs, and these files have 
not been tested extensively with Emacs on non-Android platforms. From 
the viewpoint of non-Android Emacs platforms, it's significantly less 
disruptive if merging the Android branch does not add 69 new source 
files that will require testing on these platforms.

And even from the Android viewpoint, no matter what we do to fix the 
problem some testing needs to be done anyway, as the fix is likely to 
affect Emacs in test-relevant ways.

So I propose that we merge the master branch into feature/android (to 
get the recent fix to stop using %n) and then apply the attached 
patches. The first and third patches are the actual idea. The second 
patch (compressed to save space) is automatically generated via 
admin/merge-gnulib, and consists of deleting the 69 source files.

The idea is to get feature/android merged quickly. We can revisit the 
use of Gnulib's printf-posix module later, as needed. With luck 
printf-posix won't be needed, as Emacs historically has avoided use of 
unusual printf features (for obvious portability reasons).

[-- Attachment #2: 0001-Omit-Gnulib-printf-posix-and-vasnprintf-posix.patch --]
[-- Type: text/x-patch, Size: 1159 bytes --]

From 93d3a009f7d6b5b35790c2ac5e68e66999a6e030 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 6 Aug 2023 09:40:33 -0700
Subject: [PATCH 1/3] Omit Gnulib printf-posix and vasnprintf-posix

These Gnulib modules were needed only for the %n format,
and Emacs no longer uses that format.  Also, they were causing
trouble with Emacs's specialized Gnulib importation procedure.
* admin/merge-gnulib (GNULIB_MODULES): Omit printf-posix,
vasnprintf-posix.
---
 admin/merge-gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index a0dbaae1519..b533f69cceb 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -42,7 +42,7 @@ GNULIB_MODULES=
   manywarnings memmem-simple mempcpy memrchr memset_explicit
   minmax mkostemp mktime
   nanosleep nproc nstrftime
-  pathmax pipe2 printf-posix vasprintf-posix pselect pthread_sigmask
+  pathmax pipe2 pselect pthread_sigmask
   qcopy-acl readlink readlinkat regex
   sig2str sigdescr_np socklen stat-time std-gnu11 stdbool stdckdint stddef stdio
   stpcpy stpncpy strnlen strnlen strtoimax symlink sys_stat sys_time
-- 
2.39.2


[-- Attachment #3: 0002-Regenerate-by-running-admin-merge-gnulib.patch.gz --]
[-- Type: application/gzip, Size: 118024 bytes --]

[-- Attachment #4: 0003-Do-not-define-HAVE_CONFIG_H.patch --]
[-- Type: text/x-patch, Size: 860 bytes --]

From 635234839394ca071a4fbb985233cf1bf1c9735f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 6 Aug 2023 10:32:54 -0700
Subject: [PATCH 3/3] Do not define HAVE_CONFIG_H

* configure.ac (CFLAGS): No need for -DHAVE_CONFIG_H
since Emacs no longer uses Gnulib's printf modules.
---
 configure.ac | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index c77fab3eefd..493582d42c4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7019,9 +7019,6 @@ AC_DEFUN
   [Short copyright string for this version of Emacs.])
 AC_SUBST([copyright])
 
-# This is needed for gnulib's printf modules.
-CFLAGS="$CFLAGS -DHAVE_CONFIG_H"
-
 ### Specify what sort of things we'll be editing into Makefile and config.h.
 ### Use configuration here uncanonicalized to avoid exceeding size limits.
 AC_SUBST([version])
-- 
2.39.2

Re: Android port

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 10:44:09 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, angelo.g0@libero.it, emacs-devel@gnu.org,
>  Bruno Haible <bruno@clisp.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> I understand the reluctance from the Android point of view. However, 
> printf-posix imports 69 new source files to Emacs, and these files have 
> not been tested extensively with Emacs on non-Android platforms. From 
> the viewpoint of non-Android Emacs platforms, it's significantly less 
> disruptive if merging the Android branch does not add 69 new source 
> files that will require testing on these platforms.
> 
> And even from the Android viewpoint, no matter what we do to fix the 
> problem some testing needs to be done anyway, as the fix is likely to 
> affect Emacs in test-relevant ways.

I think Paul makes a good point here about those modules not being
tested in Emacs on other platforms.  Avoiding addition of 69 files to
Emacs is also a non-trivial gain.

Since Emacs 30.1 will not be released any time soon, I think we will
have ample time to test it without the *printf modules, and find out
and fix any issues this could create.

So I suggest to give this solution a chance.

> The idea is to get feature/android merged quickly. We can revisit the 
> use of Gnulib's printf-posix module later, as needed. With luck 
> printf-posix won't be needed, as Emacs historically has avoided use of 
> unusual printf features (for obvious portability reasons).

Right.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 6 Aug 2023 10:44:09 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>, angelo.g0@libero.it, emacs-devel@gnu.org,
>>  Bruno Haible <bruno@clisp.org>
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> 
>> I understand the reluctance from the Android point of view. However, 
>> printf-posix imports 69 new source files to Emacs, and these files have 
>> not been tested extensively with Emacs on non-Android platforms. From 
>> the viewpoint of non-Android Emacs platforms, it's significantly less 
>> disruptive if merging the Android branch does not add 69 new source 
>> files that will require testing on these platforms.
>> 
>> And even from the Android viewpoint, no matter what we do to fix the 
>> problem some testing needs to be done anyway, as the fix is likely to 
>> affect Emacs in test-relevant ways.
>
> I think Paul makes a good point here about those modules not being
> tested in Emacs on other platforms.  Avoiding addition of 69 files to
> Emacs is also a non-trivial gain.
>
> Since Emacs 30.1 will not be released any time soon, I think we will
> have ample time to test it without the *printf modules, and find out
> and fix any issues this could create.
>
> So I suggest to give this solution a chance.
>
>> The idea is to get feature/android merged quickly. We can revisit the 
>> use of Gnulib's printf-posix module later, as needed. With luck 
>> printf-posix won't be needed, as Emacs historically has avoided use of 
>> unusual printf features (for obvious portability reasons).
>
> Right.

I plan to quickly test this on some old versions of Android and ack.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Sun, 6 Aug 2023 10:44:09 -0700
>>> Cc: Eli Zaretskii <eliz@gnu.org>, angelo.g0@libero.it, emacs-devel@gnu.org,
>>>  Bruno Haible <bruno@clisp.org>
>>> From: Paul Eggert <eggert@cs.ucla.edu>
>>> 
>>> I understand the reluctance from the Android point of view. However, 
>>> printf-posix imports 69 new source files to Emacs, and these files have 
>>> not been tested extensively with Emacs on non-Android platforms. From 
>>> the viewpoint of non-Android Emacs platforms, it's significantly less 
>>> disruptive if merging the Android branch does not add 69 new source 
>>> files that will require testing on these platforms.
>>> 
>>> And even from the Android viewpoint, no matter what we do to fix the 
>>> problem some testing needs to be done anyway, as the fix is likely to 
>>> affect Emacs in test-relevant ways.
>>
>> I think Paul makes a good point here about those modules not being
>> tested in Emacs on other platforms.  Avoiding addition of 69 files to
>> Emacs is also a non-trivial gain.
>>
>> Since Emacs 30.1 will not be released any time soon, I think we will
>> have ample time to test it without the *printf modules, and find out
>> and fix any issues this could create.
>>
>> So I suggest to give this solution a chance.
>>
>>> The idea is to get feature/android merged quickly. We can revisit the 
>>> use of Gnulib's printf-posix module later, as needed. With luck 
>>> printf-posix won't be needed, as Emacs historically has avoided use of 
>>> unusual printf features (for obvious portability reasons).
>>
>> Right.
>
> I plan to quickly test this on some old versions of Android and ack.

Cursory inspection indicates that Emacs functions correctly without the
*printf modules on Android 2.3, 4.0.1 and 4.4, so I've ommitted the
modules and merged the branch to master, after removing the w32-specific
code that disables them.

Thanks for your help.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  angelo.g0@libero.it,
>   emacs-devel@gnu.org,  bruno@clisp.org
> Date: Mon, 07 Aug 2023 08:49:35 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> Date: Sun, 6 Aug 2023 10:44:09 -0700
> >>> Cc: Eli Zaretskii <eliz@gnu.org>, angelo.g0@libero.it, emacs-devel@gnu.org,
> >>>  Bruno Haible <bruno@clisp.org>
> >>> From: Paul Eggert <eggert@cs.ucla.edu>
> >>> 
> >>> I understand the reluctance from the Android point of view. However, 
> >>> printf-posix imports 69 new source files to Emacs, and these files have 
> >>> not been tested extensively with Emacs on non-Android platforms. From 
> >>> the viewpoint of non-Android Emacs platforms, it's significantly less 
> >>> disruptive if merging the Android branch does not add 69 new source 
> >>> files that will require testing on these platforms.
> >>> 
> >>> And even from the Android viewpoint, no matter what we do to fix the 
> >>> problem some testing needs to be done anyway, as the fix is likely to 
> >>> affect Emacs in test-relevant ways.
> >>
> >> I think Paul makes a good point here about those modules not being
> >> tested in Emacs on other platforms.  Avoiding addition of 69 files to
> >> Emacs is also a non-trivial gain.
> >>
> >> Since Emacs 30.1 will not be released any time soon, I think we will
> >> have ample time to test it without the *printf modules, and find out
> >> and fix any issues this could create.
> >>
> >> So I suggest to give this solution a chance.
> >>
> >>> The idea is to get feature/android merged quickly. We can revisit the 
> >>> use of Gnulib's printf-posix module later, as needed. With luck 
> >>> printf-posix won't be needed, as Emacs historically has avoided use of 
> >>> unusual printf features (for obvious portability reasons).
> >>
> >> Right.
> >
> > I plan to quickly test this on some old versions of Android and ack.
> 
> Cursory inspection indicates that Emacs functions correctly without the
> *printf modules on Android 2.3, 4.0.1 and 4.4, so I've ommitted the
> modules and merged the branch to master, after removing the w32-specific
> code that disables them.

Thanks.  It looks like nt/gnulib-cfg.mk still names modules that were
eventually removed?  Could you please audit the modules added to
gnulib-cfg.mk and remove the lines that are no longer needed on
master?

Re: Android port

[Eli Zaretskii]

> Date: Mon, 07 Aug 2023 14:19:57 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, angelo.g0@libero.it, emacs-devel@gnu.org,
>  bruno@clisp.org
> 
> Thanks.  It looks like nt/gnulib-cfg.mk still names modules that were
> eventually removed?  Could you please audit the modules added to
> gnulib-cfg.mk and remove the lines that are no longer needed on
> master?

Also, it looks like neither ENABLE_CHECKING nor GLYPH_DEBUG are being
defined in src/config.h in the non-Android builds, although I passed
the --enable-checking-'yes,glyphs' option to the configure script.
This has something to do with this snippet of configure.ac:

  AS_IF([test "x$XCONFIGURE" = "xandroid" \
	 && test "x$android_enable_checking" = "xyes"],
    [ac_enable_checking=yes])

  # There is little point in enabling checking in the build machine if
  # cross-compiling for Android.
  AS_IF([test -z "$with_android" || test -n "$XCONFIGURE"],[
    if test x$ac_enable_checking != x ; then
      AC_DEFINE([ENABLE_CHECKING], [1],
    [Define to 1 if expensive run-time data type and consistency checks are enabled.])
    fi

It generates the following code in configure:

  # This environment variable is used to signal that checking should be
  # enabled on Android.  When that happens, simply enable checking for
  # the cross-compiled Android binary.

  if test "x$XCONFIGURE" = "xandroid" \
	 && test "x$android_enable_checking" = "xyes"; then :  <<<<<<<<<<<<
    ac_enable_checking=yes
  fi

  # There is little point in enabling checking in the build machine if
  # cross-compiling for Android.
  if test -z "$with_android" || test -n "$XCONFIGURE"; then :  <<<<<<<<<<<<

    if test x$ac_enable_checking != x ; then

  $as_echo "#define ENABLE_CHECKING 1" >>confdefs.h

    fi

and I believe that those colons ':' after 'then' are the culprit.  But
my Autoconf-fu is not strong enough to see what has to be done to fix
this.

Re: Android port

[Eli Zaretskii]

> Date: Mon, 07 Aug 2023 15:03:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Also, it looks like neither ENABLE_CHECKING nor GLYPH_DEBUG are being
> defined in src/config.h in the non-Android builds, although I passed
> the --enable-checking-'yes,glyphs' option to the configure script.
> This has something to do with this snippet of configure.ac:

No, it was because the Android test was incorrect.  Now fixed.

Btw, I don't think I understand the "test -n" part here:

  # There is little point in enabling checking in the build machine if
  # cross-compiling for Android.
  AS_IF([test "$with_android" = no || test -n "$XCONFIGURE"],[
    if test x$ac_enable_checking != x ; then
      AC_DEFINE([ENABLE_CHECKING], [1],
    [Define to 1 if expensive run-time data type and consistency checks are enabled.])
    fi

It sounds like "test -n" there contradicts the comment: AFAIK non-zero
length of $XCONFIGURE means we _are_ cross-compiling, and the comment
says we don't want ENABLE_CHECKING in that case.

Or maybe I don't understand the comment?

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Also, would someone ascertain if the branch still builds on MS Windows, after the past few updates from Gnulib?
>
> No, on MSYS2/MINGW64 it fails:
>
> ============================
> [...]
>  ===> Building ...
>
> make actual-all || make advice-on-failure make-target=all exit-status=$?
> make[1]: ingresso nella directory «/tmp/emacs-master»
> make -C lib all
> make -C doc/lispref info
> make -C doc/lispintro info
> make -C doc/emacs info
> make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispintro»
> /usr/bin/mkdir -p ../../info
> make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispref»
> /usr/bin/mkdir -p ../../info
>   GEN      info/dir
>   GEN      ../../info/eintr.info
> make[2]: ingresso nella directory «/tmp/emacs-master/doc/emacs»
>   GEN      ../../info/emacs.info
>   GEN      ../../info/elisp.info
> make[2]: ingresso nella directory «/tmp/emacs-master/lib»
>   GEN      alloca.h
>   GEN      byteswap.h
>   GEN      errno.h
>   GEN      execinfo.h
>   GEN      getopt.h
>   GEN      getopt-cdefs.h
>   GEN      malloc/dynarray.gl.h
>   GEN      malloc/dynarray-skeleton.gl.h
>   GEN      ieee754.h
>   GEN      limits.h
>   GEN      stdckdint.h
>   GEN      stddef.h
>   GEN      stdint.h
>   GEN      string.h
>   GEN      sys/random.h
>   GEN      time.h
>   CC       fingerprint.o
>   CC       acl_entries.o
>   CC       asnprintf.o
>   CC       asprintf.o
>   CC       frexp.o
>   CC       memmem.o
>   CC       mktime.o
>   CC       printf.o
> asprintf.c:30:1: error: redefinition of 'asprintf'
>    30 | asprintf (char **resultp, const char *format, ...)
>       | ^~~~~~~~
> In file included from C:/msys64/tmp/emacs-master/nt/inc/ms-w32.h:389,
>                  from ../src/conf_post.h:38,
>                  from ../src/config.h:3511,
>                  from asprintf.c:18:
> C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
>   276 | int asprintf(char **__ret, const char *__format, ...)
>       |     ^~~~~~~~

Thanks.  What about after applying the following change and rerunning
configure?

diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index e8b4711f548..68e264fde4c 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -178,9 +178,11 @@ gl_cv_func_printf_sizes_c99=yes
 gl_cv_func_printf_long_double=yes
 gl_cv_func_printf_infinite_long_double=yes
 gl_cv_func_printf_directive_a=yes
+gl_cv_func_printf_directive_b=yes
 gl_cv_func_printf_directive_f=yes
 gl_cv_func_printf_directive_n=yes
 gl_cv_func_printf_directive_ls=yes
+gl_cv_func_printf_directive_lc=yes
 gl_cv_func_printf_positions=yes
 gl_cv_func_printf_flag_grouping=yes
 gl_cv_func_printf_flag_leftadjust=yes

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Fri, 04 Aug 2023 17:44:11 +0800
> 
> Thanks.  What about after applying the following change and rerunning
> configure?
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index e8b4711f548..68e264fde4c 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -178,9 +178,11 @@ gl_cv_func_printf_sizes_c99=yes
>  gl_cv_func_printf_long_double=yes
>  gl_cv_func_printf_infinite_long_double=yes
>  gl_cv_func_printf_directive_a=yes
> +gl_cv_func_printf_directive_b=yes
>  gl_cv_func_printf_directive_f=yes
>  gl_cv_func_printf_directive_n=yes
>  gl_cv_func_printf_directive_ls=yes
> +gl_cv_func_printf_directive_lc=yes
>  gl_cv_func_printf_positions=yes
>  gl_cv_func_printf_flag_grouping=yes
>  gl_cv_func_printf_flag_leftadjust=yes

If MinGW doesn't support those directives, the above is not TRT, it
might cause future maintenance headaches.

I don't think MSVCRT.DLL's implementation of printf supports those, at
least not on all versions of Windows.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Fri, 04 Aug 2023 17:44:11 +0800
>> 
>> Thanks.  What about after applying the following change and rerunning
>> configure?
>> 
>> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
>> index e8b4711f548..68e264fde4c 100644
>> --- a/nt/mingw-cfg.site
>> +++ b/nt/mingw-cfg.site
>> @@ -178,9 +178,11 @@ gl_cv_func_printf_sizes_c99=yes
>>  gl_cv_func_printf_long_double=yes
>>  gl_cv_func_printf_infinite_long_double=yes
>>  gl_cv_func_printf_directive_a=yes
>> +gl_cv_func_printf_directive_b=yes
>>  gl_cv_func_printf_directive_f=yes
>>  gl_cv_func_printf_directive_n=yes
>>  gl_cv_func_printf_directive_ls=yes
>> +gl_cv_func_printf_directive_lc=yes
>>  gl_cv_func_printf_positions=yes
>>  gl_cv_func_printf_flag_grouping=yes
>>  gl_cv_func_printf_flag_leftadjust=yes
>
> If MinGW doesn't support those directives, the above is not TRT, it
> might cause future maintenance headaches.
>
> I don't think MSVCRT.DLL's implementation of printf supports those, at
> least not on all versions of Windows.

Those flags are how Gnulib users are meant to disable the printf-posix
module, though.  Angelo, would you please provide your config.log?  It
would assist me in determining which printf features Gnulib is still
striving to replace.

Re: Android port

[Angelo Graziosi]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

> Il 04/08/2023 14:02 CEST Po Lu ha scritto:
> 

> 
> Angelo, would you please provide your config.log?  It
> would assist me in determining which printf features Gnulib is still
> striving to replace.

Attached...

[-- Attachment #2: config_log.tar.gz --]
[-- Type: application/gzip, Size: 95605 bytes --]

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 04/08/2023 14:02 CEST Po Lu ha scritto:
>> 
>
>> 
>> Angelo, would you please provide your config.log?  It
>> would assist me in determining which printf features Gnulib is still
>> striving to replace.
>
> Attached...

Thanks, what if you apply this patch on top of the previous one?
Like last time, please re-run configure.

diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index 68e264fde4c..f78ee525bf1 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
 enable_xattr=no
 # Don't build gnulib printf either.
 gl_cv_func_printf_sizes_c99=yes
+gl_cv_func_printf_sizes_c23=yes
 gl_cv_func_printf_long_double=yes
 gl_cv_func_printf_infinite_long_double=yes
 gl_cv_func_printf_directive_a=yes

Re: Android port

[Corwin Brust]

On Fri, Aug 4, 2023 at 8:17 AM Po Lu <luangruo@yahoo.com> wrote:
>
> Angelo Graziosi <angelo.g0@libero.it> writes:
>
> Thanks, what if you apply this patch on top of the previous one?
> Like last time, please re-run configure.
>

With both patches applied I'm able to build feature/android under
MSYS2/MinGW64.  I am trying a 32 bit build now.

Re: Android port

[Corwin Brust]

On Fri, Aug 4, 2023 at 8:37 AM Corwin Brust <corwin@bru.st> wrote:
>
> With both patches applied I'm able to build feature/android under
> MSYS2/MinGW64.  I am trying a 32 bit build now.

That build also succeeded; I can run the resulting runemacs.exe from
MinGW32; it "works".

Re: Android port

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Fri, 4 Aug 2023 22:24:09 -0500
> Cc: Angelo Graziosi <angelo.g0@libero.it>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Fri, Aug 4, 2023 at 8:37 AM Corwin Brust <corwin@bru.st> wrote:
> >
> > With both patches applied I'm able to build feature/android under
> > MSYS2/MinGW64.  I am trying a 32 bit build now.
> 
> That build also succeeded; I can run the resulting runemacs.exe from
> MinGW32; it "works".

On which version of MS-Windows did you test the 32-bit build?

And thanks for yours and Angelo's efforts in validating this branch.

Re: Android port

[Corwin Brust]

On Sat, Aug 5, 2023 at 1:46 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Fri, 4 Aug 2023 22:24:09 -0500
> > Cc: Angelo Graziosi <angelo.g0@libero.it>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >
> > On Fri, Aug 4, 2023 at 8:37 AM Corwin Brust <corwin@bru.st> wrote:
> > >
> > > With both patches applied I'm able to build feature/android under
> > > MSYS2/MinGW64.  I am trying a 32 bit build now.
> >
> > That build also succeeded; I can run the resulting runemacs.exe from
> > MinGW32; it "works".
>
> On which version of MS-Windows did you test the 32-bit build?

I have Windows 10 Home (22H2) OS Build:19045.3271
On the off chance it helps, I have Windows Feature Experience Pack
1000.19041.1000.0

I launched Emacs (in my x64 bit environment) from:

MINGW32_NT-10.0-19045 Avalon 3.3.4-341.x86_64 2022-02-15 17:24 UTC x86_64 Msys

>
> And thanks for yours and Angelo's efforts in validating this branch.
>

Very much a pleasure.

Re: Android port

[Angelo Graziosi]

> Il 04/08/2023 15:17 CEST Po Lu ha scritto:
> 
> Thanks, what if you apply this patch on top of the previous one?
> Like last time, please re-run configure.
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index 68e264fde4c..f78ee525bf1 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
>  enable_xattr=no
>  # Don't build gnulib printf either.
>  gl_cv_func_printf_sizes_c99=yes
> +gl_cv_func_printf_sizes_c23=yes
>  gl_cv_func_printf_long_double=yes
>  gl_cv_func_printf_infinite_long_double=yes
>  gl_cv_func_printf_directive_a=yes

Now it builds.. I am using it..

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 04 Aug 2023 21:17:47 +0800
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index 68e264fde4c..f78ee525bf1 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
>  enable_xattr=no
>  # Don't build gnulib printf either.
>  gl_cv_func_printf_sizes_c99=yes
> +gl_cv_func_printf_sizes_c23=yes
>  gl_cv_func_printf_long_double=yes
>  gl_cv_func_printf_infinite_long_double=yes
>  gl_cv_func_printf_directive_a=yes

What feature does the gl_cv_func_printf_sizes_c23 variable test?  Does
MinGW printf indeed support that feature?  If not, we are lying to the
configure script, and that is not TRT.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 04 Aug 2023 21:17:47 +0800
>> 
>> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
>> index 68e264fde4c..f78ee525bf1 100644
>> --- a/nt/mingw-cfg.site
>> +++ b/nt/mingw-cfg.site
>> @@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
>>  enable_xattr=no
>>  # Don't build gnulib printf either.
>>  gl_cv_func_printf_sizes_c99=yes
>> +gl_cv_func_printf_sizes_c23=yes
>>  gl_cv_func_printf_long_double=yes
>>  gl_cv_func_printf_infinite_long_double=yes
>>  gl_cv_func_printf_directive_a=yes
>
> What feature does the gl_cv_func_printf_sizes_c23 variable test?  Does
> MinGW printf indeed support that feature?  If not, we are lying to the
> configure script, and that is not TRT.

We are deceiving the configure script, but that's the only ``supported''
way to disable the printf* modules, as they aren't subject to the normal
Make-based controls in gnulib.mk.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
> Date: Sat, 05 Aug 2023 09:04:54 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> >> Date: Fri, 04 Aug 2023 21:17:47 +0800
> >> 
> >> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> >> index 68e264fde4c..f78ee525bf1 100644
> >> --- a/nt/mingw-cfg.site
> >> +++ b/nt/mingw-cfg.site
> >> @@ -175,6 +175,7 @@ gl_cv_func_nanosleep=yes
> >>  enable_xattr=no
> >>  # Don't build gnulib printf either.
> >>  gl_cv_func_printf_sizes_c99=yes
> >> +gl_cv_func_printf_sizes_c23=yes
> >>  gl_cv_func_printf_long_double=yes
> >>  gl_cv_func_printf_infinite_long_double=yes
> >>  gl_cv_func_printf_directive_a=yes
> >
> > What feature does the gl_cv_func_printf_sizes_c23 variable test?  Does
> > MinGW printf indeed support that feature?  If not, we are lying to the
> > configure script, and that is not TRT.
> 
> We are deceiving the configure script, but that's the only ``supported''
> way to disable the printf* modules, as they aren't subject to the normal
> Make-based controls in gnulib.mk.

I'm sorry, but such a solution is not acceptable, as it will be a
maintenance headache, if and when we actually need these features in
Emacs.  We must find a cleaner solution.

Let's wait for the Gnulib folks to chime in and suggest better ways of
solving this.

Re: Android port

[Angelo Graziosi]

No, same failure...
> Il 04/08/2023 11:44 CEST Po Lu ha scritto:
> 
>  
> Angelo Graziosi writes:
> 
> >> Also, would someone ascertain if the branch still builds on MS Windows, after the past few updates from Gnulib?
> >
> > No, on MSYS2/MINGW64 it fails:
> >
> > ============================
> > [...]
> >  ===> Building ...
> >
> > make actual-all || make advice-on-failure make-target=all exit-status=$?
> > make[1]: ingresso nella directory «/tmp/emacs-master»
> > make -C lib all
> > make -C doc/lispref info
> > make -C doc/lispintro info
> > make -C doc/emacs info
> > make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispintro»
> > /usr/bin/mkdir -p ../../info
> > make[2]: ingresso nella directory «/tmp/emacs-master/doc/lispref»
> > /usr/bin/mkdir -p ../../info
> >   GEN      info/dir
> >   GEN      ../../info/eintr.info
> > make[2]: ingresso nella directory «/tmp/emacs-master/doc/emacs»
> >   GEN      ../../info/emacs.info
> >   GEN      ../../info/elisp.info
> > make[2]: ingresso nella directory «/tmp/emacs-master/lib»
> >   GEN      alloca.h
> >   GEN      byteswap.h
> >   GEN      errno.h
> >   GEN      execinfo.h
> >   GEN      getopt.h
> >   GEN      getopt-cdefs.h
> >   GEN      malloc/dynarray.gl.h
> >   GEN      malloc/dynarray-skeleton.gl.h
> >   GEN      ieee754.h
> >   GEN      limits.h
> >   GEN      stdckdint.h
> >   GEN      stddef.h
> >   GEN      stdint.h
> >   GEN      string.h
> >   GEN      sys/random.h
> >   GEN      time.h
> >   CC       fingerprint.o
> >   CC       acl_entries.o
> >   CC       asnprintf.o
> >   CC       asprintf.o
> >   CC       frexp.o
> >   CC       memmem.o
> >   CC       mktime.o
> >   CC       printf.o
> > asprintf.c:30:1: error: redefinition of 'asprintf'
> >    30 | asprintf (char **resultp, const char *format, ...)
> >       | ^~~~~~~~
> > In file included from C:/msys64/tmp/emacs-master/nt/inc/ms-w32.h:389,
> >                  from ../src/conf_post.h:38,
> >                  from ../src/config.h:3511,
> >                  from asprintf.c:18:
> > C:/msys64/mingw64/include/stdio.h:276:5: note: previous definition of 'asprintf' with type 'int(char **, const char *, ...)'
> >   276 | int asprintf(char **__ret, const char *__format, ...)
> >       |     ^~~~~~~~
> 
> Thanks.  What about after applying the following change and rerunning
> configure?
> 
> diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
> index e8b4711f548..68e264fde4c 100644
> --- a/nt/mingw-cfg.site
> +++ b/nt/mingw-cfg.site
> @@ -178,9 +178,11 @@ gl_cv_func_printf_sizes_c99=yes
>  gl_cv_func_printf_long_double=yes
>  gl_cv_func_printf_infinite_long_double=yes
>  gl_cv_func_printf_directive_a=yes
> +gl_cv_func_printf_directive_b=yes
>  gl_cv_func_printf_directive_f=yes
>  gl_cv_func_printf_directive_n=yes
>  gl_cv_func_printf_directive_ls=yes
> +gl_cv_func_printf_directive_lc=yes
>  gl_cv_func_printf_positions=yes
>  gl_cv_func_printf_flag_grouping=yes
>  gl_cv_func_printf_flag_leftadjust=yes

Android port

[Po Lu]

I have _really_ finished writing the Android port, and that includes a
new ``virtual filesystem'' component which enables Emacs to directly
edit (in contrast to merely reading) files and directories inside
document providers, such as network attached storage client programs.

No consensus was built the previous time we debated whether to include
this code or not, but with Emacs 29.1 out the door and master relatively
calm, I would like to revisit this subject.

I've already had gobs of people employ my inbox as a substitute for the
bug tracker, confirming my earlier apprehensions.  Furthermore, several
users have obtained my organizational e-mail by hook or by crook, and
used it for petty banter concerning design and UI decisions made there,
leading to unpleasant inquiries from my management regarding the
adequate use of organizational resources.  As such, I hold no continued
interest in _publishing_ updates to this port, unless it is clearly
presented as part of GNU Emacs instead of a one man show.  Judging by
the abundance of discourse misdirected at me, it seems to interest more
than a negligible portion of the Emacs user populace, some of whom use
the branch for its improved touch-screen support outside of Android.

Also, would someone ascertain if the branch still builds on MS Windows,
after the past few updates from Gnulib?

TIA.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Fri, 04 Aug 2023 12:12:26 +0800
> 
> No consensus was built the previous time we debated whether to include
> this code or not, but with Emacs 29.1 out the door and master relatively
> calm, I would like to revisit this subject.

There's no need to revisit, from where I stand.  It is quite clear
this community as a whole thinks that having the port as part of Emacs
is more important than the potential difficulties and issues it could
create.

> Also, would someone ascertain if the branch still builds on MS Windows,
> after the past few updates from Gnulib?

Once Someone™ confirms that the MinGW and NS builds work on that
branch, you can go ahead and land the branch on master.  (But please
be sure to make a proper log message naming all the new files and
changes in existing ones, when you merge.)

And a huge thanks for working on this port.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Date: Fri, 04 Aug 2023 12:12:26 +0800
>> 
>> No consensus was built the previous time we debated whether to include
>> this code or not, but with Emacs 29.1 out the door and master relatively
>> calm, I would like to revisit this subject.
>
> There's no need to revisit, from where I stand.  It is quite clear
> this community as a whole thinks that having the port as part of Emacs
> is more important than the potential difficulties and issues it could
> create.
>
>> Also, would someone ascertain if the branch still builds on MS Windows,
>> after the past few updates from Gnulib?
>
> Once Someone™ confirms that the MinGW and NS builds work on that
> branch, you can go ahead and land the branch on master.  (But please
> be sure to make a proper log message naming all the new files and
> changes in existing ones, when you merge.)
>
> And a huge thanks for working on this port.

Thanks everyone for your support as well.  And please, direct comments
and questions to the Emacs development lists, and _not_ my inbox.

Re: Android port

[Po Lu]

Mohsen Banan <emacs@mohsen.1.banan.byname.net> writes:

> Hello,
>
> First, thank you very much for your wonderful work.
>
> I have started experimenting with it and have some
> questions that are likely too basic for the
> emacs-devel mailing list.

The appropriate list for these questions is help-gnu-emacs@gnu.org,
which I've copied in.  That list is archived and is also gatewayed into
Usenet, so questions and answers sent there will benefit more people
than those directed to me personally.

> 1) ---------
> Po> I believe the Android port of Emacs is now
> Po> more or less feature complete.
>
> Indeed it is. But the enlarge/zoom gesture did not
> work for me. I like that in termux.
> Has that feature been implemented? Do you plan to
> implement it? In the android environment, I think
> that feature is very valuable.

I've never found it necessary, so patches welcome, I guess.  See
lisp/touch-screen.el.

> 2) -----------
> Po> Follow the instructions in INSTALL.android
> Po> to build and install Emacs for your specific device.
>
> There is no INSTALL.android
> in the clone that I got with:
> git clone git://git.sv.gnu.org/emacs.git -b feature/android
>
> Has there been changes to that?

That document has been moved to `java/INSTALL'.

> 3) ----------
> I experimented with perso-arabic text (e.g.,
> persian tutorial) and the default fonts do not
> support it. Any advice on what font to use and how
> to select it in emacs and in android?
>
> I'll be happy to work with you on this as after
> the font chalenge, there may also be problems with shaping
> (harfbaz, ...)

Font shaping via HarfBuzz has been implemented and is now included in
all prebuilts for 64 bit architectures.  However, Emacs only supports
TrueType fonts, so I suggest installing the TrueType version Noto Sans
Arabic.

The procedure for installing fonts is described in (emacs)Android Fonts.

> 4) ----------
> I want to combine the use of emacs and termux.
> This is something that many would want to do.
> I found:
> https://marek-g.github.io/posts/tips_and_tricks/emacs_on_android/
> but the prebuilt emacs at
> https://github.com/marek-g/emacs-config/releases
> did not work for me.
>
> Would be great, if these two could be integrated
> out of the box.

Emacs is now capable of running subprocesses regardless of system
restrictions, so you should be able to build

  https://github.com/termux/termux-packages/

with the prefix changed to `org.gnu.emacs', and to simply install
the resulting archives in Emacs's home directory.

> ===========
>
> I have not done any Android development in the
> past but if you were willing to guide me a bit, I can
> likely come to speed and I do want to contribute
> towards an out of the box perso-arabic android
> emacs.
>
> Thanks and regards,
>
> ...Mohsen

Thanks for your interest in Emacs.  Fortunately, very little Android
specific knowledge is required to work on the Android port; a good
understanding of C and font scaling should be enough.

Re: Android port

[Angelo Graziosi]

Just out of curiosity,

Po Lu wrote:

> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.

I see (https://f-droid.org/it/packages/org.gnu.emacs) the package was added on 2023-02-09.. Why is it not "good"? has it been built with your method or does it belong to another project? Which?

There it says the package is for Android >= 5.1 while you says your work is for Android > 2...

TIA,
 Angelo.

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> I see (https://f-droid.org/it/packages/org.gnu.emacs) the package was
> added on 2023-02-09.. Why is it not "good"? has it been built with
> your method or does it belong to another project? Which?

It was made 10 days ago.

> There it says the package is for Android >= 5.1 while you says your
> work is for Android > 2...

The C compiler they used is too new for the resulting binary to work on
older versions of Android.

Emacs is not like other programs, where one binary can run on any number
of systems.  You should build Emacs for an API level reasonably close to
what you will install it on, and with the right C compiler for that.

Otherwise, you will get gnulib substitutes for several system functions,
which may not be what you want.

Re: Android port

[Angelo Graziosi]

> Il 18/02/2023 09:42 Po Lu ha scritto:
> 
> It was made 10 days ago.
> 

I gave a try to the F-Droid package installing it on a device with android 11. I use this device with mouse and keyboard (the delete key does not work in Emacs). 

I enabled Emacs to have access to all the files.

When I start Emacs there is a notification [See (emacs) Android Environment for more details about this notification]: what it means is a mystery.

The font on this system is too small and I would increase it as I do, for example, with my build on GNU/Linux. But How is this font called? I cannot establish this from Options - Set Default Font

It seems that HOME (~/) is "/data/data/org.gnu/files" which cannot be accessed from, for example, Termux (this app has access to /data/data/com.termux/). So it is hard (but not impossible) to comunicate with the "external world" (for example to move an init.el, taken from another system,  to ~/.emacs.d/: this would facilitate the setup of this android Emacs.

In any case, I created a ~/.emacs.d/init.el and added something like

(global-tab-line-mode 1)

(setq tab-line-tabs-function 'tab-line-tabs-buffer-groups)
(setq tab-line-close-tab-function 'kill-buffer)

(setq auto-save-list-file-prefix nil)

(column-number-mode 1)
(delete-selection-mode 1)
(electric-pair-mode 1)
(savehist-mode 1)
(tool-bar-mode -1)

Needless to say, Emacs crashes all the time and I have to try many times to write that. And if I add

(desktop-save-mode 1)

it crashes during startup, mainly if one want to load desktop file blocked by the lock file left there by previous crash..

BTW, the About Emacs says it is a

  build 1, aarch64-unknown-linux-android220 of 2023-02-18

Why 2023-02-18 if the package was made 10 days ago?

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> I gave a try to the F-Droid package installing it on a device with
> android 11. I use this device with mouse and keyboard (the delete key
> does not work in Emacs).
>
> I enabled Emacs to have access to all the files.
>
> When I start Emacs there is a notification [See (emacs) Android
> Environment for more details about this notification]: what it means
> is a mystery.

As it says, you should read the node ``Android Environment'' in the
Emacs manual.  This notification is displayed to prevent Emacs from
being killed after entering the background.

> The font on this system is too small and I would increase it as I do,
> for example, with my build on GNU/Linux. But How is this font called?
> I cannot establish this from Options - Set Default Font
>
> It seems that HOME (~/) is "/data/data/org.gnu/files" which cannot be
> accessed from, for example, Termux (this app has access to
> /data/data/com.termux/). So it is hard (but not impossible) to
> comunicate with the "external world" (for example to move an init.el,
> taken from another system, to ~/.emacs.d/: this would facilitate the
> setup of this android Emacs.

Android security policy prevents applications from accessing each others
home directories, so yes, it is not easy to access.

Copying an init.el from another system is best done through the system
file manager or by copying the files into Emacs's home directory via the
external storage.

File managers on most proprietary versions of Android refuse to display
Emacs's home directory, because they are more keen to display
advertisements than to actually manage files.

> In any case, I created a ~/.emacs.d/init.el and added something like
>
> (global-tab-line-mode 1)
>
> (setq tab-line-tabs-function 'tab-line-tabs-buffer-groups)
> (setq tab-line-close-tab-function 'kill-buffer)
>
> (setq auto-save-list-file-prefix nil)
>
> (column-number-mode 1)
> (delete-selection-mode 1)
> (electric-pair-mode 1)
> (savehist-mode 1)
> (tool-bar-mode -1)
>
> Needless to say, Emacs crashes all the time and I have to try many
> times to write that. And if I add

First, try with an up to date build.  Next, please show the output of
the following command with your device connected to a computer (once
again, this is described in the Android appendix of the Emacs manual, so
please read it.)

  adb logcat | grep android_run_debug_thread

> (desktop-save-mode 1)
>
> it crashes during startup, mainly if one want to load desktop file
> blocked by the lock file left there by previous crash..

I will look into that.

> BTW, the About Emacs says it is a
>
>   build 1, aarch64-unknown-linux-android220 of 2023-02-18
>
> Why 2023-02-18 if the package was made 10 days ago?

Android does not correctly report the date of an executable.
It is always the present.

Re: Android port

[Angelo Graziosi]

> Il 19/02/2023 03:13 Po Lu ha scritto:
> 
> As it says, you should read the node ``Android Environment'' in the
> Emacs manual.  This notification is displayed to prevent Emacs from
> being killed after entering the background.

I did but many things are still unclear..

> Copying an init.el from another system is best done through the system
> file manager or by copying the files into Emacs's home directory via the
> external storage.
> 

Here the file manager does not show Emacs directory.. or at least I cannot find it.. It is unclear the last sentence: from Emacs I can visit a file, say in /sdcard/Download/, but HOW copy it in Emacs, say in ~/?

> File managers on most proprietary versions of Android refuse to display
> Emacs's home directory, because they are more keen to display
> advertisements than to actually manage files.

..so this way could be unusable here...


> First, try with an up to date build.  

Let's wait for an F-Droid update, then..

> 
>   adb logcat | grep android_run_debug_thread
> 

to run the above or similar I should install adb on GNU/Linux (Mint in my case)? and how to connect the device? with its cable? I never did this because I transfer files via ssh and similar.. BTW, I have adb installed in Termux on the same device.. I wonder if I can use that..

In any case,
 Thanks!

Re: Android port

[Dov Grobgeld]

Finally something that I can answer. :-)

To use adb on Linux you need to do the following:

1. Enable debug mode on the android device. The way you do this
depends on the device, but it typically involves tapping five to seven
times on the system about kernel version. Look for it on the web.
2. After enabling debug mode looking for "USB debugging" on the device
and turn it on.
3. Connect the android device to the computer by cable.
4. Run `adb shell` on your computer. This will fail to connect because
of permissions.
5. On the android device you will get a popup asking whether you want
to allow usb debugging from your computer. Confirm this.
6. Back in the computer terminal do a `killall adb` to remove the
previous adb process (it installs itself as a server). And redo it.
7. You will now have a shell into your device. :-)

You can use adb to copy files `adb push` and `adb pull` to the device.

You can also use `adb logcat` and filter the output by regexps.

Hope this helps!

Looking forward to using emacs on my android tablet!

Dov


On Sun, Feb 19, 2023 at 11:02 AM Angelo Graziosi <angelo.g0@libero.it> wrote:
>
>
> > Il 19/02/2023 03:13 Po Lu ha scritto:
> >
> > As it says, you should read the node ``Android Environment'' in the
> > Emacs manual.  This notification is displayed to prevent Emacs from
> > being killed after entering the background.
>
> I did but many things are still unclear..
>
> > Copying an init.el from another system is best done through the system
> > file manager or by copying the files into Emacs's home directory via the
> > external storage.
> >
>
> Here the file manager does not show Emacs directory.. or at least I cannot find it.. It is unclear the last sentence: from Emacs I can visit a file, say in /sdcard/Download/, but HOW copy it in Emacs, say in ~/?
>
> > File managers on most proprietary versions of Android refuse to display
> > Emacs's home directory, because they are more keen to display
> > advertisements than to actually manage files.
>
> ..so this way could be unusable here...
>
>
> > First, try with an up to date build.
>
> Let's wait for an F-Droid update, then..
>
> >
> >   adb logcat | grep android_run_debug_thread
> >
>
> to run the above or similar I should install adb on GNU/Linux (Mint in my case)? and how to connect the device? with its cable? I never did this because I transfer files via ssh and similar.. BTW, I have adb installed in Termux on the same device.. I wonder if I can use that..
>
> In any case,
>  Thanks!
>

Re: Android port

[Michael Albinus]

Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> To use adb on Linux you need to do the following:
>
> 1. Enable debug mode on the android device. The way you do this
> depends on the device, but it typically involves tapping five to seven
> times on the system about kernel version. Look for it on the web.
> 2. After enabling debug mode looking for "USB debugging" on the device
> and turn it on.
> 3. Connect the android device to the computer by cable.
> 4. Run `adb shell` on your computer. This will fail to connect because
> of permissions.
> 5. On the android device you will get a popup asking whether you want
> to allow usb debugging from your computer. Confirm this.
> 6. Back in the computer terminal do a `killall adb` to remove the
> previous adb process (it installs itself as a server). And redo it.
> 7. You will now have a shell into your device. :-)
>
> You can use adb to copy files `adb push` and `adb pull` to the device.
>
> You can also use `adb logcat` and filter the output by regexps.

In Emacs, there's also Tramp's "adb" method. If you have only one
Android device, you can access it via "C-x C-f /adb::" from your local
Emacs, running on Linux.

The only missing feature is support of "adb logcat". Shall we add
something like this?

> Hope this helps!
>
> Looking forward to using emacs on my android tablet!
>
> Dov

Best regards, Michael.

Re: Android port

[Po Lu]

Michael Albinus <michael.albinus@gmx.de> writes:

> Dov Grobgeld <dov.grobgeld@gmail.com> writes:
>
>> To use adb on Linux you need to do the following:
>>
>> 1. Enable debug mode on the android device. The way you do this
>> depends on the device, but it typically involves tapping five to seven
>> times on the system about kernel version. Look for it on the web.
>> 2. After enabling debug mode looking for "USB debugging" on the device
>> and turn it on.
>> 3. Connect the android device to the computer by cable.
>> 4. Run `adb shell` on your computer. This will fail to connect because
>> of permissions.
>> 5. On the android device you will get a popup asking whether you want
>> to allow usb debugging from your computer. Confirm this.
>> 6. Back in the computer terminal do a `killall adb` to remove the
>> previous adb process (it installs itself as a server). And redo it.
>> 7. You will now have a shell into your device. :-)
>>
>> You can use adb to copy files `adb push` and `adb pull` to the device.
>>
>> You can also use `adb logcat` and filter the output by regexps.
>
> In Emacs, there's also Tramp's "adb" method. If you have only one
> Android device, you can access it via "C-x C-f /adb::" from your local
> Emacs, running on Linux.
>
> The only missing feature is support of "adb logcat". Shall we add
> something like this?

If you run `logcat' from a directory in /adb::, it will work just as
well as if you ran `adb logcat'.

Re: Android port

[Michael Albinus]

Po Lu <luangruo@yahoo.com> writes:

Hi,

>> In Emacs, there's also Tramp's "adb" method. If you have only one
>> Android device, you can access it via "C-x C-f /adb::" from your local
>> Emacs, running on Linux.
>>
>> The only missing feature is support of "adb logcat". Shall we add
>> something like this?
>
> If you run `logcat' from a directory in /adb::, it will work just as
> well as if you ran `adb logcat'.

Great. Tramp's adb method supports remote processes. so with a proper
default-directory, one can call from Emacs

--8<---------------cut here---------------start------------->8---
(async-shell-command "logcat | grep android_run_debug_thread")
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Re: Android port

[Po Lu]

Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> Finally something that I can answer. :-)
>
> To use adb on Linux you need to do the following:
>
> 1. Enable debug mode on the android device. The way you do this
> depends on the device, but it typically involves tapping five to seven
> times on the system about kernel version. Look for it on the web.
> 2. After enabling debug mode looking for "USB debugging" on the device
> and turn it on.
> 3. Connect the android device to the computer by cable.
> 4. Run `adb shell` on your computer. This will fail to connect because
> of permissions.
> 5. On the android device you will get a popup asking whether you want
> to allow usb debugging from your computer. Confirm this.
> 6. Back in the computer terminal do a `killall adb` to remove the
> previous adb process (it installs itself as a server). And redo it.
> 7. You will now have a shell into your device. :-)
>
> You can use adb to copy files `adb push` and `adb pull` to the device.
>
> You can also use `adb logcat` and filter the output by regexps.
>
> Hope this helps!
>
> Looking forward to using emacs on my android tablet!

Thanks.

Everyone, do we need this information in the Emacs manual?

Re: Android port

[Angelo Graziosi]

> Il 19/02/2023 11:55 Po Lu ha scritto:
> 
>  
> Dov Grobgeld writes:
> 
> > Finally something that I can answer. :-)
> >
> > To use adb on Linux you need to do the following:
> >
> > 1. Enable debug mode on the android device. The way you do this
> > depends on the device, but it typically involves tapping five to seven
> > times on the system about kernel version. Look for it on the web.
> > 2. After enabling debug mode looking for "USB debugging" on the device
> > and turn it on.
> > 3. Connect the android device to the computer by cable.
> > 4. Run `adb shell` on your computer. This will fail to connect because
> > of permissions.
> > 5. On the android device you will get a popup asking whether you want
> > to allow usb debugging from your computer. Confirm this.
> > 6. Back in the computer terminal do a `killall adb` to remove the
> > previous adb process (it installs itself as a server). And redo it.
> > 7. You will now have a shell into your device. :-)
> >
> > You can use adb to copy files `adb push` and `adb pull` to the device.
> >
> > You can also use `adb logcat` and filter the output by regexps.
> >
> > Hope this helps!
> >
> > Looking forward to using emacs on my android tablet!
> 
> Thanks.
> 
> Everyone, do we need this information in the Emacs manual?

+1

Re: Android port

[Peter Oliver]

Po Lu writes:

> Dov Grobgeld writes:
>
>> To use adb on Linux you need to do the following:
>>
>> 1. Enable debug mode on the android device. The way you do this
>> depends on the device, but it typically involves tapping five to seven
>> times on the system about kernel version. Look for it on the web.
>> 2. After enabling debug mode looking for "USB debugging" on the device
>> and turn it on.
>> 3. Connect the android device to the computer by cable.
>> 4. Run `adb shell` on your computer. This will fail to connect because
>> of permissions.
>> 5. On the android device you will get a popup asking whether you want
>> to allow usb debugging from your computer. Confirm this.
>> 6. Back in the computer terminal do a `killall adb` to remove the
>> previous adb process (it installs itself as a server). And redo it.
>> 7. You will now have a shell into your device. :-)
>>
>> You can use adb to copy files `adb push` and `adb pull` to the device.
>>
>> You can also use `adb logcat` and filter the output by regexps.
>
> Everyone, do we need this information in the Emacs manual?

Yes, but better to direct users to the official documentation (https://developer.android.com/studio/command-line/adb) rather than try to describe it ourselves, I think.

-- 
Peter Oliver

Re: Android port

[Po Lu]

Peter Oliver <p.d.oliver@mavit.org.uk> writes:

> Yes, but better to direct users to the official documentation (https://developer.android.com/studio/command-line/adb) rather than try to describe it ourselves, I think.

I think I will write both down in the manual.
Thanks for bringing this up.

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

Hi,

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 19/02/2023 03:13 Po Lu ha scritto:
>> 
>> As it says, you should read the node ``Android Environment'' in the
>> Emacs manual.  This notification is displayed to prevent Emacs from
>> being killed after entering the background.
>
> I did but many things are still unclear..
>
>> Copying an init.el from another system is best done through the system
>> file manager or by copying the files into Emacs's home directory via the
>> external storage.
>> 
>
> Here the file manager does not show Emacs directory.. or at least I cannot find
> it.. It is unclear the last sentence: from Emacs I can visit a file, say in
> /sdcard/Download/, but HOW copy it in Emacs, say in ~/?

On my device, which uses a near-vanilla build of AOSP, Emacs is visible
in the hamburger menu on the left in the Files app, below the SD card
option, and above Termux.  Do you see something similar on your device?

>> File managers on most proprietary versions of Android refuse to display
>> Emacs's home directory, because they are more keen to display
>> advertisements than to actually manage files.
>
> ..so this way could be unusable here...
>
>
>> First, try with an up to date build.  
>
> Let's wait for an F-Droid update, then..

FWIW, I could reproduce this on 1f81186d67b2a86e6a555a7ad3323fcd13f5e257
but not c8f49c9276d34741bfbe7752dd38391c0b8d782b, so, it may be fixed.

>> 
>>   adb logcat | grep android_run_debug_thread
>> 
>
> to run the above or similar I should install adb on GNU/Linux (Mint in my
> case)? and how to connect the device? with its cable? I never did this because
> I transfer files via ssh and similar.. BTW, I have adb installed in Termux on
> the same device.. I wonder if I can use that..

You could, technically, though it's likely easier to do it on your PC.
Enable USB debugging, install the adb package.  Your normal
charging/data transfer cable ought to work.

> In any case,
>  Thanks!

Have a nice day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Copying an init.el from another system is best done through the system
>> file manager or by copying the files into Emacs's home directory via the
>> external storage.
>> 
>
> Here the file manager does not show Emacs directory.. or at least I
> cannot find it.. It is unclear the last sentence: from Emacs I can
> visit a file, say in /sdcard/Download/, but HOW copy it in Emacs, say
> in ~/?

If you click the three line menu on the top left, the file manager
should display a panel containing a list of mounted ``volumes''.

A volume labelled ``Emacs home directory'' should be visible.

>> File managers on most proprietary versions of Android refuse to display
>> Emacs's home directory, because they are more keen to display
>> advertisements than to actually manage files.
>
> ..so this way could be unusable here...

Too bad.

>> First, try with an up to date build.  
>
> Let's wait for an F-Droid update, then..
>
>> 
>>   adb logcat | grep android_run_debug_thread
>> 
>
> to run the above or similar I should install adb on GNU/Linux (Mint in
> my case)? and how to connect the device? with its cable? I never did
> this because I transfer files via ssh and similar.. BTW, I have adb
> installed in Termux on the same device.. I wonder if I can use that..

That will not work, unless you connect your phone to itself via its adb
port.

Re: Android port

[Angelo Graziosi]

> Il 19/02/2023 11:53 Po Lu ha scritto:
> 
> 
> If you click the three line menu on the top left, the file manager
> should display a panel containing a list of mounted ``volumes''.
> 
> A volume labelled ``Emacs home directory'' should be visible.

The navigation bar collapses in 6 icons:

- Recent files
- Documents
- Download
- Installation files
- Internal Memory
- Analyze memory

 
> >> File managers on most proprietary versions of Android refuse to display
> >> Emacs's home directory, because they are more keen to display
> >> advertisements than to actually manage files.
> >
> > ..so this way could be unusable here...
> 
> Too bad.

Ever since there was the upgrade to android 11 problems began...

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> The navigation bar collapses in 6 icons:
>
> - Recent files
> - Documents
> - Download
> - Installation files
> - Internal Memory
> - Analyze memory

I guess the best thing to do is to try installing a version of Android
on your device that will let you use Android's own free file manager.
Alternatively, copy the file(s) to `/sdcard' and then copy them to
Emacs's home directory from inside Emacs.

> Ever since there was the upgrade to android 11 problems began...

It would be more appropriate to call such changes to your system
downgrades.

Re: Android port

[Angelo Graziosi]

> Il 19/02/2023 12:59 Po Lu ha scritto:
> 
> Alternatively, copy the file(s) to `/sdcard' and then copy them to
> Emacs's home directory from inside Emacs.

What I thought... Dired should help. right? or there is a better way? (notice rarely I used dired...)

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 19/02/2023 12:59 Po Lu ha scritto:
>> 
>> Alternatively, copy the file(s) to `/sdcard' and then copy them to
>> Emacs's home directory from inside Emacs.
>
> What I thought... Dired should help. right? or there is a better way? (notice rarely I used dired...)

Dired, or running `cp' in a shell buffer.

Re: Android port

[Angelo Graziosi]

On GNU/Linux (Mint) I change the size of default (Monospace) font with

(set-frame-font "Monospace-11" nil t)

(setq default-frame-alist
      '(
        ;;(width . 120) ; character
        ;;(height . 54) ; lines
        ;;(left . (- 0)); pixel
        ;;(top  . (+ 0)); pixel
        ;;(left . 835); pixel
        ;;(top  .   0); pixel
        (font . "Monospace-11") ; font
        ))

in the init.el file. How can I do the same with this android Emacs? I cannot establish the name of the font it is using...

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> On GNU/Linux (Mint) I change the size of default (Monospace) font with
>
> (set-frame-font "Monospace-11" nil t)
>
> (setq default-frame-alist
>       '(
>         ;;(width . 120) ; character
>         ;;(height . 54) ; lines
>         ;;(left . (- 0)); pixel
>         ;;(top  . (+ 0)); pixel
>         ;;(left . 835); pixel
>         ;;(top  .   0); pixel
>         (font . "Monospace-11") ; font
>         ))
>
> in the init.el file. How can I do the same with this android Emacs? I cannot establish the name of the font it is using...

As the manual says, ``Droid Sans Mono''.

Re: Android port

[Angelo Graziosi]

> Il 21/02/2023 03:28 Po Lu <luangruo@yahoo.com> ha scritto:
> 
>  
> Angelo Graziosi <angelo.g0@libero.it> writes:
> 
> > On GNU/Linux (Mint) I change the size of default (Monospace) font with
> >
> > (set-frame-font "Monospace-11" nil t)
> >
> > (setq default-frame-alist
> >       '(
> >         ;;(width . 120) ; character
> >         ;;(height . 54) ; lines
> >         ;;(left . (- 0)); pixel
> >         ;;(top  . (+ 0)); pixel
> >         ;;(left . 835); pixel
> >         ;;(top  .   0); pixel
> >         (font . "Monospace-11") ; font
> >         ))
> >
> > in the init.el file. How can I do the same with this android Emacs? I cannot establish the name of the font it is using...
> 
> As the manual says, ``Droid Sans Mono''.

Thanks.

I tried the last binaries (emacs-30.0.50-21-arm64-v8a.apk) and copied almost the full .emacs.d I have on GNU/Linux (with the elpa/melpa packages etc.). The result almost works but there are the following issues:

- some "random" crash (3-4 in few hours)

- when in the init file I have:

   (global-auto-revert-mode 1)

  the device vibrates and in the minibuffer shows up: "Error while reading file system events: try again". So I commented that out

- when i click on the Options menu the minibuffer shows: "Wrong type argument: stringp, nil" and the menu does not open. The other menu (File, Edit etc open regularly)

- last but not least, the DELETE key on the keyboard does not work.

It seem you have don big step forward!

Re: Android port

[Jonathan Kenyon]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

If I could chime in here. One other issue I see is some keybinds throw a
"C-x <text-conversion> is undefined". Is this something other people are
seeing? Specifically C-x  h and C-x o

On Tue, Feb 21, 2023 at 11:40 AM Angelo Graziosi <angelo.g0@libero.it>
wrote:

>
> > Il 21/02/2023 03:28 Po Lu <luangruo@yahoo.com> ha scritto:
> >
> >
> > Angelo Graziosi <angelo.g0@libero.it> writes:
> >
> > > On GNU/Linux (Mint) I change the size of default (Monospace) font with
> > >
> > > (set-frame-font "Monospace-11" nil t)
> > >
> > > (setq default-frame-alist
> > >       '(
> > >         ;;(width . 120) ; character
> > >         ;;(height . 54) ; lines
> > >         ;;(left . (- 0)); pixel
> > >         ;;(top  . (+ 0)); pixel
> > >         ;;(left . 835); pixel
> > >         ;;(top  .   0); pixel
> > >         (font . "Monospace-11") ; font
> > >         ))
> > >
> > > in the init.el file. How can I do the same with this android Emacs? I
> cannot establish the name of the font it is using...
> >
> > As the manual says, ``Droid Sans Mono''.
>
> Thanks.
>
> I tried the last binaries (emacs-30.0.50-21-arm64-v8a.apk) and copied
> almost the full .emacs.d I have on GNU/Linux (with the elpa/melpa packages
> etc.). The result almost works but there are the following issues:
>
> - some "random" crash (3-4 in few hours)
>
> - when in the init file I have:
>
>    (global-auto-revert-mode 1)
>
>   the device vibrates and in the minibuffer shows up: "Error while reading
> file system events: try again". So I commented that out
>
> - when i click on the Options menu the minibuffer shows: "Wrong type
> argument: stringp, nil" and the menu does not open. The other menu (File,
> Edit etc open regularly)
>
> - last but not least, the DELETE key on the keyboard does not work.
>
> It seem you have don big step forward!
>
>

[-- Attachment #2: Type: text/html, Size: 2625 bytes --]

Re: Android port

[Jonathan Kenyon]

[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

> One other issue I see is some keybinds throw a "C-x <text-conversion> is
undefined"

This actually only applies to software keyboards, not hardware, so there
must be some layer of translation happening from Android before it gets to
emacs.

On Tue, Feb 21, 2023, 11:51 AM Jonathan Kenyon <J.Kenyon@ordinarygizmos.com>
wrote:

> If I could chime in here. One other issue I see is some keybinds throw a
> "C-x <text-conversion> is undefined". Is this something other people are
> seeing? Specifically C-x  h and C-x o
>
> On Tue, Feb 21, 2023 at 11:40 AM Angelo Graziosi <angelo.g0@libero.it>
> wrote:
>
>>
>> > Il 21/02/2023 03:28 Po Lu <luangruo@yahoo.com> ha scritto:
>> >
>> >
>> > Angelo Graziosi <angelo.g0@libero.it> writes:
>> >
>> > > On GNU/Linux (Mint) I change the size of default (Monospace) font with
>> > >
>> > > (set-frame-font "Monospace-11" nil t)
>> > >
>> > > (setq default-frame-alist
>> > >       '(
>> > >         ;;(width . 120) ; character
>> > >         ;;(height . 54) ; lines
>> > >         ;;(left . (- 0)); pixel
>> > >         ;;(top  . (+ 0)); pixel
>> > >         ;;(left . 835); pixel
>> > >         ;;(top  .   0); pixel
>> > >         (font . "Monospace-11") ; font
>> > >         ))
>> > >
>> > > in the init.el file. How can I do the same with this android Emacs? I
>> cannot establish the name of the font it is using...
>> >
>> > As the manual says, ``Droid Sans Mono''.
>>
>> Thanks.
>>
>> I tried the last binaries (emacs-30.0.50-21-arm64-v8a.apk) and copied
>> almost the full .emacs.d I have on GNU/Linux (with the elpa/melpa packages
>> etc.). The result almost works but there are the following issues:
>>
>> - some "random" crash (3-4 in few hours)
>>
>> - when in the init file I have:
>>
>>    (global-auto-revert-mode 1)
>>
>>   the device vibrates and in the minibuffer shows up: "Error while
>> reading file system events: try again". So I commented that out
>>
>> - when i click on the Options menu the minibuffer shows: "Wrong type
>> argument: stringp, nil" and the menu does not open. The other menu (File,
>> Edit etc open regularly)
>>
>> - last but not least, the DELETE key on the keyboard does not work.
>>
>> It seem you have don big step forward!
>>
>>

[-- Attachment #2: Type: text/html, Size: 3380 bytes --]

Re: Android port

[Simon Pugnet]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

Jonathan Kenyon <J.Kenyon@ordinarygizmos.com> writes:

>> One other issue I see is some keybinds throw a "C-x <text-conversion> is undefined"
>
> This actually only applies to software keyboards, not hardware, so there must be some layer of translation happening from Android before it gets to emacs.

I was seeing this problem too and I managed to fix it by using: -

(add-hook 'after-change-major-mode-hook (lambda () (set-text-conversion-style nil)))

There's a new section in the manual describing what "text conversions"
are and I used the information there to find out how to disable it. The
above hook is just a quick way to disable it in every buffer but I'm
sure it's just a workaround and that there's a better fix.

I hope that helps!

Kind regards,

Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Android port

[Po Lu]

Simon Pugnet <simon@polaris64.net> writes:

> I was seeing this problem too and I managed to fix it by using: -
>
> (add-hook 'after-change-major-mode-hook (lambda () (set-text-conversion-style nil)))
>
> There's a new section in the manual describing what "text conversions"
> are and I used the information there to find out how to disable it. The
> above hook is just a quick way to disable it in every buffer but I'm
> sure it's just a workaround and that there's a better fix.

If you do this, your input method will no longer work properly.
It would be better to fix the individual keyboards to not perform text
conversion after a modifier key is pressed.

Re: Android port

[Jonathan Kenyon]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

> What keyboard are you using?

It happened with both Hacker's Keyboard and AnySoftKeyboard. I can't seem
to coerce it into entering the debugger since it's not truly an error.

I'll see about getting a trace.

On Tue, Feb 21, 2023, 8:35 PM Po Lu <luangruo@yahoo.com> wrote:

> Simon Pugnet <simon@polaris64.net> writes:
>
> > I was seeing this problem too and I managed to fix it by using: -
> >
> > (add-hook 'after-change-major-mode-hook (lambda ()
> (set-text-conversion-style nil)))
> >
> > There's a new section in the manual describing what "text conversions"
> > are and I used the information there to find out how to disable it. The
> > above hook is just a quick way to disable it in every buffer but I'm
> > sure it's just a workaround and that there's a better fix.
>
> If you do this, your input method will no longer work properly.
> It would be better to fix the individual keyboards to not perform text
> conversion after a modifier key is pressed.
>

[-- Attachment #2: Type: text/html, Size: 1704 bytes --]

Re: Android port

[Po Lu]

Jonathan Kenyon <J.Kenyon@ordinarygizmos.com> writes:

>> What keyboard are you using?
>
> It happened with both Hacker's Keyboard and AnySoftKeyboard. I can't seem to coerce it into entering the debugger since it's not truly an
> error.
>
> I'll see about getting a trace.

No need, I will just disable text conversion while reading key
sequences.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Jonathan Kenyon <J.Kenyon@ordinarygizmos.com> writes:
>
>>> What keyboard are you using?
>>
>> It happened with both Hacker's Keyboard and AnySoftKeyboard. I can't seem to coerce it into entering the debugger since it's not truly an
>> error.
>>
>> I'll see about getting a trace.
>
> No need, I will just disable text conversion while reading key
> sequences.

Angelo, Simon, Jonathan: the Options menu and text conversion issues
should now be fixed on the branch.  I've uploaded a new prebuilt to
SourceForge as well, at the same URL as the old one.

Thanks for testing.

Re: Android port

[Simon Pugnet]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Jonathan Kenyon <J.Kenyon@ordinarygizmos.com> writes:
>>
>>>> What keyboard are you using?
>>>
>>> It happened with both Hacker's Keyboard and AnySoftKeyboard. I 
>>> can't seem to coerce it into entering the debugger since it's not 
>>> truly an
>>> error.
>>>
>>> I'll see about getting a trace.
>>
>> No need, I will just disable text conversion while reading key
>> sequences.
>
> Angelo, Simon, Jonathan: the Options menu and text conversion issues
> should now be fixed on the branch.  I've uploaded a new prebuilt to
> SourceForge as well, at the same URL as the old one.

Thanks for looking into this issue. I've just rebuilt and tested and I 
can see that the problem is now solved for key sequences such as "C-h 
f".

However I use Evil and I also have trouble with using h,j,k,l to move 
the point in Evil's normal state. For example I would expect "j" to 
move the point down by one line (using `evil-next-visual-line') 
however when I press "j" in the Android version then I can see that it 
instead does the following: -

  <text-conversion> runs the command analyze-text-conversion (found in 
  global map), which is an interactive byte-compiled Lisp function in 
  'simple.el'.

Disabling text conversion with `(set-text-conversion-style nil)' 
allows those keys to function as expected.

> Thanks for testing.

You're welcome, happy to do so!

Kind regards,

-- 
Simon Pugnet
https://www.polaris64.net/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Android port

[Angelo Graziosi]

> Il 22/02/2023 15:11 Po Lu ha scritto:
> 

> Angelo, Simon, Jonathan: the Options menu and text conversion issues
> should now be fixed on the branch.  I've uploaded a new prebuilt to
> SourceForge as well, at the same URL as the old one.

Yes, Options is fixed. Thanks.

Just for completeness, now when I press the DELETE key (on keyboard) in the minibuffer shows up this:

<KEYCODE_FOWARD_DEL> is undefined

Re: Android port

[Angelo Graziosi]

> Il 22/02/2023 15:11 Po Lu ha scritto:
> 


> I've uploaded a new prebuilt to
> SourceForge as well, at the same URL as the old one.
> 
> Thanks for testing.

The last today APK does not install here (android 11):

   App not installed

it says..

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 22/02/2023 15:11 Po Lu ha scritto:
>> 
>
>
>> I've uploaded a new prebuilt to
>> SourceForge as well, at the same URL as the old one.
>> 
>> Thanks for testing.
>
> The last today APK does not install here (android 11):
>
>    App not installed
>
> it says..

Right, please try again.  Thanks.

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 22/02/2023 15:11 Po Lu ha scritto:
>> 
>
>
>> I've uploaded a new prebuilt to
>> SourceForge as well, at the same URL as the old one.
>> 
>> Thanks for testing.
>
> The last today APK does not install here (android 11):
>
>    App not installed
>
> it says..

Please try again, something happened during the upload.

Re: Android port

[Angelo Graziosi]

> Il 24/02/2023 02:01 Po Lu ha scritto:
> 
> Please try again, something happened during the upload.

Yes, now it works..

Re: Android port

[Po Lu]

Jonathan Kenyon <J.Kenyon@ordinarygizmos.com> writes:

> If I could chime in here. One other issue I see is some keybinds throw
> a "C-x <text-conversion> is undefined". Is this something other people
> are seeing? Specifically C-x h and C-x o

What keyboard are you using?  Text conversion should not happen when the
keyboard is sending ordinary prefix key events.

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

>> Il 21/02/2023 03:28 Po Lu <luangruo@yahoo.com> ha scritto:
>> 
>>  
>> Angelo Graziosi <angelo.g0@libero.it> writes:
>> 
>> > On GNU/Linux (Mint) I change the size of default (Monospace) font with
>> >
>> > (set-frame-font "Monospace-11" nil t)
>> >
>> > (setq default-frame-alist
>> >       '(
>> >         ;;(width . 120) ; character
>> >         ;;(height . 54) ; lines
>> >         ;;(left . (- 0)); pixel
>> >         ;;(top  . (+ 0)); pixel
>> >         ;;(left . 835); pixel
>> >         ;;(top  .   0); pixel
>> >         (font . "Monospace-11") ; font
>> >         ))
>> >
>> > in the init.el file. How can I do the same with this android Emacs? I cannot establish the name of the font it is using...
>> 
>> As the manual says, ``Droid Sans Mono''.
>
> Thanks.
>
> I tried the last binaries (emacs-30.0.50-21-arm64-v8a.apk) and copied almost the full .emacs.d I have on GNU/Linux (with the elpa/melpa packages etc.). The result almost works but there are the following issues:
>
> - some "random" crash (3-4 in few hours)
>
> - when in the init file I have:
>
>    (global-auto-revert-mode 1)
>
>   the device vibrates and in the minibuffer shows up: "Error while reading file system events: try again". So I commented that out
>
> - when i click on the Options menu the minibuffer shows: "Wrong type argument: stringp, nil" and the menu does not open. The other menu (File, Edit etc open regularly)
>
> - last but not least, the DELETE key on the keyboard does not work.
>
> It seem you have don big step forward!

Please show backtraces for all of those crashes.  The options menu works
here, so please show a backtrace from that too (`toggle-debug-on-error'.)

And, what keyboard are you using?

Re: Android port

[Angelo Graziosi]

> Il 22/02/2023 03:30 Po Lu ha scritto:
> 
> Please show backtraces for all of those crashes.  The options menu works
> here, so please show a backtrace from that too (`toggle-debug-on-error'.)

When I click on Options it prints in backtrace buffer:

Debugger entered... : (void-variable scroll-bar-mode)
(eq scroll-bar-mode nil)

Just this.. Why it happens only with this menu item and not with the others.. Notice that File menu item and some other have a scroll-bar and they works...

When it crashes it closes I don't see anything.

> And, what keyboard are you using?

Moko-atic Keyboard

Re: Android port

[Angelo Graziosi]

> Il 22/02/2023 03:30 Po Lu ha scritto:
> 
> And, what keyboard are you using?

This: https://preview.redd.it/na8vbzzq29i81.jpg?width=640&crop=smart&auto=webp&s=683a57d3fba12f4ba505e291ab6cdca965ea807c

Re: Android port

[Angelo Graziosi]

> Il 21/02/2023 18:39 Angelo Graziosi ha scritto:
> 
> I tried the last binaries (emacs-30.0.50-21-arm64-v8a.apk) and copied almost the full .emacs.d I have on GNU/Linux (with the elpa/melpa packages etc.). The result almost works but there are the following issues:
> - when in the init file I have:
> 
>    (global-auto-revert-mode 1)
> 
>   the device vibrates and in the minibuffer shows up: "Error while reading file system events: try again". So I commented that out

This still occurs with the last emacs-30.0.50-21-arm64-v8a.apk.. to which "master" it refers?

BTW, in the init.el I have

;; Native buffer tabs setup
(global-tab-line-mode 1)

(setq tab-line-tabs-function 'tab-line-tabs-buffer-groups)
(setq tab-line-close-tab-function 'kill-buffer)

(set-face-attribute 'tab-line nil
                    :height 1.0
                    :inherit 'default)

and when I click tabs to switch/close buffers Emacs crashes (closes) more or less randomly...

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> This still occurs with the last emacs-30.0.50-21-arm64-v8a.apk.. to which "master" it refers?

That one.  So please show a backtrace, thanks.

> BTW, in the init.el I have
>
> ;; Native buffer tabs setup
> (global-tab-line-mode 1)
>
> (setq tab-line-tabs-function 'tab-line-tabs-buffer-groups)
> (setq tab-line-close-tab-function 'kill-buffer)
>
> (set-face-attribute 'tab-line nil
>                     :height 1.0
>                     :inherit 'default)
>
> and when I click tabs to switch/close buffers Emacs crashes (closes) more or less randomly...

Please show a backtrace from the crash.  If you run ``adb logcat'' and
wait for it to print everything, you can grep for:

  *** *** *** ***

the backtrace will follow the asterisks.

Re: Android port

[Angelo Graziosi]

> Il 06/03/2023 00:57 Po Lu ha scritto:
> 
> Please show a backtrace from the crash.  If you run ``adb logcat'' and
> wait for it to print everything, you can grep for:
> 
>   *** *** *** ***
> 
> the backtrace will follow the asterisks.

I do not have time to learn this , now.

Just for the record, today update fails systematically at start up...

Re: Android port

[Po Lu]

You should get a backtrace if you want this to be fixed, because I can't read your mind (and your phone) from all the way over here.

Thanks.


On March 7, 2023 11:47:31 PM GMT+08:00, Angelo Graziosi <angelo.g0@libero.it> wrote:
>
>> Il 06/03/2023 00:57 Po Lu ha scritto:
>> 
>> Please show a backtrace from the crash.  If you run ``adb logcat'' and
>> wait for it to print everything, you can grep for:
>> 
>>   *** *** *** ***
>> 
>> the backtrace will follow the asterisks.
>
>I do not have time to learn this , now.
>
>Just for the record, today update fails systematically at start up...

Re: Android port

[Angelo Graziosi]

> Il 08/03/2023 00:58 Po Lu ha scritto:
> 
>  
> You should get a backtrace if you want this to be fixed, because I can't read your mind (and your phone) from all the way over here.

Maybe when I have more time.

> On March 7 Angelo Graziosi wrote:
> >Just for the record, today update fails systematically at start up...

How do you explain that with yesterday and today APK Emacs crashes at start up IF IT FINDS a desktop file?

I have in the init.el

(setq desktop-base-file-name "~/.emacs.d/desktop")

If I remove it (EShell), Emacs starts; if I quit it and save a desktop file (just when Emacs displays the scratch buffer), then re-launching it crashes, i.e. immediately closes. 

At least the previous APKs worked.. for a while

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> How do you explain that with yesterday and today APK Emacs crashes at start up IF IT FINDS a desktop file?
>
> I have in the init.el
>
> (setq desktop-base-file-name "~/.emacs.d/desktop")
>
> If I remove it (EShell), Emacs starts; if I quit it and save a desktop file (just when Emacs displays the scratch buffer), then re-launching it crashes, i.e. immediately closes. 
>
> At least the previous APKs worked.. for a while

I don't know.  But I don't see any crash here.
I will ask some other people to try this.

Re: Android port

[Angelo Graziosi]

> Il 09/03/2023 02:22 Po Lu ha scritto:
> 
>  
> Angelo Graziosi  writes:
> 
> > How do you explain that with yesterday and today APK Emacs crashes at start up IF IT FINDS a desktop file?
> >
>
> I don't know.  But I don't see any crash here.
> I will ask some other people to try this.

Just for the record, today upgrade seems to fix this issue!

Re: Android port

[Angelo Graziosi]

>  Po Lu  ha scritto (some month ago)...
> 
> I will ask some other people to try this.


> ... and now
> I've uploaded prebuilts to
>
>  https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/termux
>
> which can access Termux files and program data.  Brief installation
> instructions are also provided in the README.

There it says we have to uninstall the current Android port and Termux. 

Really you mean we have to reinstall Termux from scratch with **ALL* packages we have installed for years? and their configurations and so on?

It is a request very heavy to follow..

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> There it says we have to uninstall the current Android port and Termux. 

Android doesn't allow updating packages with a different signature or
shared user ID.

> Really you mean we have to reinstall Termux from scratch with **ALL*
> packages we have installed for years? and their configurations and so
> on?
>
> It is a request very heavy to follow..

If that's a concern, it's trivial to back up both files installed in
Termux:

  $ cd /data/data/com.termux
  $ tar cf /sdcard/termux.tar files

and the data from Emacs:

  $ cd /data/data/org.gnu.emacs
  $ tar cf /sdcard/emacs.tar files

before uninstalling both packages.

Re: Android port

[Jean Louis]

* Po Lu <luangruo@yahoo.com> [2023-07-17 11:33]:
> Angelo Graziosi <angelo.g0@libero.it> writes:
> 
> > There it says we have to uninstall the current Android port and Termux. 
> 
> Android doesn't allow updating packages with a different signature or
> shared user ID.
> 
> > Really you mean we have to reinstall Termux from scratch with **ALL*
> > packages we have installed for years? and their configurations and so
> > on?

Are you sure? Termux and Emacs for Android should be working together
without problem, together with Emacs inside of Termux.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port

[Angelo Graziosi]

Jean,

> Il 31/08/2023 07:51 CEST Jean Louis ha scritto:
> 
>  
> * Po Lu [2023-07-17 11:33]:
> > Angelo Graziosi writes:
> > 
> > > There it says we have to uninstall the current Android port and Termux. 
> > 
> > Android doesn't allow updating packages with a different signature or
> > shared user ID.
> > 
> > > Really you mean we have to reinstall Termux from scratch with **ALL*
> > > packages we have installed for years? and their configurations and so
> > > on?
> 
> Are you sure? Termux and Emacs for Android should be working together
> without problem, together with Emacs inside of Termux.

I am a bit confused.. Do you mean that we do not have to reinstall Termux with the Emacs package which, as stated by Po Lu, would request that?

Really I am still using the original Emacs package which does not request to reinstall Termux. Usual I put files in /sdcard/Download and access them from Emacs with C-x C-f /sdcard/Download/foo (maybe also files in /sdcard/emacs_docs should work..)

Re: Android port

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Hello,

Backing-up and restoring are described Termux-wiki,

https://wiki.termux.com/wiki/Backing_up_Termux

For me, it took an hour for tar and untar about 20GB data on
$PREFIX/{usr|home}.

Thanks,

2023年7月17日(月) 午後5:22 Angelo Graziosi <angelo.g0@libero.it>:

>
> >  Po Lu  ha scritto (some month ago)...
> >
> > I will ask some other people to try this.
>
>
> > ... and now
> > I've uploaded prebuilts to
> >
> >
> https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/termux
> >
> > which can access Termux files and program data.  Brief installation
> > instructions are also provided in the README.
>
> There it says we have to uninstall the current Android port and Termux.
>
> Really you mean we have to reinstall Termux from scratch with **ALL*
> packages we have installed for years? and their configurations and so on?
>
> It is a request very heavy to follow..
>
>

[-- Attachment #2: Type: text/html, Size: 1647 bytes --]

Re: Android port

[Angelo Graziosi]

> Il 17/07/2023 10:40 CEST Takesi Ayanokoji ha scritto:
> 
> 
> Hello,
> 
> Backing-up and restoring are described Termux-wiki,
> 
> https://wiki.termux.com/wiki/Backing_up_Termux

OK, although there, the instructions look a bit different...

May be in Emacs we should have some documentation about this argument.

Re: Android port

[Po Lu]

Angelo Graziosi <angelo.g0@libero.it> writes:

> OK, although there, the instructions look a bit different...
>
> May be in Emacs we should have some documentation about this argument.

How to set up system package repositories is outside the scope of Emacs
documentation.

Re: Android port

[Peter Oliver]

On Sun, 19 Feb 2023, Po Lu wrote:

> Copying an init.el from another system is best done through the system
> file manager or by copying the files into Emacs's home directory via the
> external storage.

Another moderately convenient option is KDE Connect, which consists of a pair of applications to run on an Android device and a normal computer to provide a range of integrations between them.  One of the integrations offered is file sharing.

It is developed by the KDE project, but using the KDE desktop is not required.

https://kdeconnect.kde.org/

-- 
Peter Oliver

Re: Android port

[Jean Louis]

* Angelo Graziosi <angelo.g0@libero.it> [2023-02-18 11:37]:
> Just out of curiosity,
> 
> Po Lu wrote:
> 
> > At present, I don't recommend using binaries from f-droid.org, since
> > they are out of date, but I will ask the f-droid packagers to rectify
> > that problem.
> 
> I see (https://f-droid.org/it/packages/org.gnu.emacs) the package was added on 2023-02-09.. Why is it not "good"? has it been built with your method or does it belong to another project? Which?

I can't play Tetris, Emacs aborts.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> * Angelo Graziosi <angelo.g0@libero.it> [2023-02-18 11:37]:
>> Just out of curiosity,
>> 
>> Po Lu wrote:
>> 
>> > At present, I don't recommend using binaries from f-droid.org, since
>> > they are out of date, but I will ask the f-droid packagers to rectify
>> > that problem.
>> 
>> I see (https://f-droid.org/it/packages/org.gnu.emacs) the package was added on 2023-02-09.. Why is it not "good"? has it been built with your method or does it belong to another project? Which?
>
> I can't play Tetris, Emacs aborts.

Please show a backtrace from ``adb logcat''.

Android port

[Po Lu]

I believe the Android port of Emacs is now more or less feature
complete.

It can be found on the feature/android branch of the Emacs repository,
and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
Android devices capable of running Android 2.2 or later.  You can obtain
a check out of that code like so:

  $ git clone git://git.sv.gnu.org/emacs.git -b feature/android

Please give it as much testing as you can on real hardware from many
different Android vendors.  Follow the instructions in INSTALL.android
to build and install Emacs for your specific device.  In addition,
please submit patches and report editing modes that do not work well
with the input methods of various on screen keyboards, along with other
bugs, using ``M-x report-emacs-bug RET.''

The answers to various common questions (such as ``how to access
external storage'', or ``where does Emacs put its init.el'') are in the
Android appendix of the Emacs manual in the branch.

Prebuilt binaries will be made available shortly, but please do not
expect them to contain all dependencies with which Emacs can be built.
At present, I don't recommend using binaries from f-droid.org, since
they are out of date, but I will ask the f-droid packagers to rectify
that problem.

I will post this news to comp.emacs; please post this to other forums
frequented by Emacs users as well.

Re: Android port

[Eric S Fraga]

On Friday, 17 Feb 2023 at 19:51, Po Lu wrote:
> I believe the Android port of Emacs is now more or less feature
> complete.

Excellent.  Thank you!

> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.

I look forward to having these binaries available.  I had already
installed an earlier version from f-droid but would like to test this
latest version.  Note that I am testing on a system probably more suited
to Emacs than the typical phone as mine has a physical keyboard: Planet
Computers Gemini.  Screenshot of Emacs on that phone:

https://fediscience.org/@ericsfraga/109863360504898593

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-02-14) on Debian 11.5

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

Hi,

Po Lu <luangruo@yahoo.com> writes:

> I believe the Android port of Emacs is now more or less feature
> complete.
>
> It can be found on the feature/android branch of the Emacs repository,
> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
> Android devices capable of running Android 2.2 or later.  You can obtain
> a check out of that code like so:
>
>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>
> Please give it as much testing as you can on real hardware from many
> different Android vendors.  Follow the instructions in INSTALL.android
> to build and install Emacs for your specific device.  In addition,
> please submit patches and report editing modes that do not work well
> with the input methods of various on screen keyboards, along with other
> bugs, using ``M-x report-emacs-bug RET.''
>
> The answers to various common questions (such as ``how to access
> external storage'', or ``where does Emacs put its init.el'') are in the
> Android appendix of the Emacs manual in the branch.
>
> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.
>
> I will post this news to comp.emacs; please post this to other forums
> frequented by Emacs users as well.

Thanks for the effort.  I was quite excited for this.

For now, I was trying to make an out-of-tree build without gnutls.  This
configuration appears to be broken (though, not due to gnutls):

  make[2]: Entering directory '/home/arsen/gnu/emacs-android/build/java'
  make[2]: *** No rule to make target '../java/Makefile.in', needed by 'Makefile'.  Stop.
  make[2]: Leaving directory '/home/arsen/gnu/emacs-android/build/java'

I'll report a fix when I come up with one.

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Hi,
>
> Po Lu <luangruo@yahoo.com> writes:
>
>> I believe the Android port of Emacs is now more or less feature
>> complete.
>>
>> It can be found on the feature/android branch of the Emacs repository,
>> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
>> Android devices capable of running Android 2.2 or later.  You can obtain
>> a check out of that code like so:
>>
>>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>>
>> Please give it as much testing as you can on real hardware from many
>> different Android vendors.  Follow the instructions in INSTALL.android
>> to build and install Emacs for your specific device.  In addition,
>> please submit patches and report editing modes that do not work well
>> with the input methods of various on screen keyboards, along with other
>> bugs, using ``M-x report-emacs-bug RET.''
>>
>> The answers to various common questions (such as ``how to access
>> external storage'', or ``where does Emacs put its init.el'') are in the
>> Android appendix of the Emacs manual in the branch.
>>
>> Prebuilt binaries will be made available shortly, but please do not
>> expect them to contain all dependencies with which Emacs can be built.
>> At present, I don't recommend using binaries from f-droid.org, since
>> they are out of date, but I will ask the f-droid packagers to rectify
>> that problem.
>>
>> I will post this news to comp.emacs; please post this to other forums
>> frequented by Emacs users as well.
>
> Thanks for the effort.  I was quite excited for this.
>
> For now, I was trying to make an out-of-tree build without gnutls.  This
> configuration appears to be broken (though, not due to gnutls):
>
>   make[2]: Entering directory '/home/arsen/gnu/emacs-android/build/java'
>   make[2]: *** No rule to make target '../java/Makefile.in', needed by 'Makefile'.  Stop.
>   make[2]: Leaving directory '/home/arsen/gnu/emacs-android/build/java'
>
> I'll report a fix when I come up with one.
>
> Have a lovely day.

Out of tree builds are currently not supported because of some specifics
related to the ``aapt'' tool and ``ndk-build'' system used by Android.

I'd not attempt wasting time trying to fix that.

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Out of tree builds are currently not supported because of some specifics
> related to the ``aapt'' tool and ``ndk-build'' system used by Android.
>
> I'd not attempt wasting time trying to fix that.

Sure.  In-tree worked as expected, and I see Emacs on the phone.  I'll
try porting more tangible parts of my scripts in a few days.

Thanks.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

Hi,

While building initially, I got some make errors that looked like they
were from a race, for example:

    GEN         execinfo.h
  mv: cannot stat 'execinfo.h-t': No such file or directory

Further confirming my suspicion that these are coming from a race is
Emacs compiling fine if make is reinvoked, and that a non-parallel make
build works fine.

I figured this was a fluke initially, but, I reproduced the issue today.
You can fetch the build log from here:
https://www.aarsen.me/~arsen/emacs-races.script

There also appears to be a dependency missing between generating the APK
and running the pdumper, or such, since I could re-run make after make
concluded in the nonparallel case.

This seems pretty reproducible on my machine, I suspect due to the large
number of -t files utilized in Gnulib.

-- 8< --

While I'm around, I was also thinking about how to enable using the
modifier keys on virtual keyboards without modifiers.  I was considering
mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
held in combination with another key, hence, the sequence Press VolDown,
Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
that I know rely on external tools (XKB configs, AHK, ...) that are not
available on android.

Thanks in advance.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Hi,
>
> While building initially, I got some make errors that looked like they
> were from a race, for example:
>
>     GEN         execinfo.h
>   mv: cannot stat 'execinfo.h-t': No such file or directory
>
> Further confirming my suspicion that these are coming from a race is
> Emacs compiling fine if make is reinvoked, and that a non-parallel make
> build works fine.
>
> I figured this was a fluke initially, but, I reproduced the issue today.
> You can fetch the build log from here:
> https://www.aarsen.me/~arsen/emacs-races.script
>
> There also appears to be a dependency missing between generating the APK
> and running the pdumper, or such, since I could re-run make after make
> concluded in the nonparallel case.

This should not be a problem, since the dumping happens on-device on
Android.

> This seems pretty reproducible on my machine, I suspect due to the large
> number of -t files utilized in Gnulib.

I will look into this, thanks.

> While I'm around, I was also thinking about how to enable using the
> modifier keys on virtual keyboards without modifiers.  I was considering
> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
> held in combination with another key, hence, the sequence Press VolDown,
> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
> that I know rely on external tools (XKB configs, AHK, ...) that are not
> available on android.

I'm not sure how to do this, since those keys are not ``meta modifiers''
on the system.

I'd recommend an on screen keyboard which has those modifier keys
instead.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi,
>>
>> While building initially, I got some make errors that looked like they
>> were from a race, for example:
>>
>>     GEN         execinfo.h
>>   mv: cannot stat 'execinfo.h-t': No such file or directory
>>
>> Further confirming my suspicion that these are coming from a race is
>> Emacs compiling fine if make is reinvoked, and that a non-parallel make
>> build works fine.
>>
>> I figured this was a fluke initially, but, I reproduced the issue today.
>> You can fetch the build log from here:
>> https://www.aarsen.me/~arsen/emacs-races.script
>>
>> There also appears to be a dependency missing between generating the APK
>> and running the pdumper, or such, since I could re-run make after make
>> concluded in the nonparallel case.
>
> This should not be a problem, since the dumping happens on-device on
> Android.
>
>> This seems pretty reproducible on my machine, I suspect due to the large
>> number of -t files utilized in Gnulib.
>
> I will look into this, thanks.
>
>> While I'm around, I was also thinking about how to enable using the
>> modifier keys on virtual keyboards without modifiers.  I was considering
>> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
>> held in combination with another key, hence, the sequence Press VolDown,
>> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
>> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
>> that I know rely on external tools (XKB configs, AHK, ...) that are not
>> available on android.
>
> I'm not sure how to do this, since those keys are not ``meta modifiers''
> on the system.
>
> I'd recommend an on screen keyboard which has those modifier keys
> instead.

Please see if the parallel build has been fixed.  Thanks.

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Please see if the parallel build has been fixed.  Thanks.

One build passed fine, so my guess is yes.  I'll let it spin for a bit
with GNU Make's --shuffle, too, and report if anything comes up.

Thanks!

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Arsen Arsenović]

[-- Attachment #1.1: Type: text/plain, Size: 4216 bytes --]

Hi,

I encountered another one:

  javac -classpath "/home/arsen/Android/Sdk/platforms/android-Tiramisu/android.jar:." -target 1.7 -source 1.7 -Xlint:d
  eprecation org/gnu/emacs/EmacsContextMenu.java
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  org/gnu/emacs/EmacsContextMenu.java:265: error: cannot find symbol
      final Holder<Boolean> rc;
            ^
    symbol:   class Holder
    location: class EmacsContextMenu
  org/gnu/emacs/EmacsContextMenu.java:267: error: cannot find symbol
      rc = new Holder<Boolean> ();
               ^
    symbol:   class Holder
    location: class EmacsContextMenu
  2 errors
  4 warnings
  make[2]: *** [Makefile:261: org/gnu/emacs/EmacsContextMenu.class] Error 1 shuffle=2758590628

I tried replicating with that shuffle= value, but it seems that I did
not get lucky twice.  However, I believe I have the reason why:

  ~/gnu/emacs-android2 130 $ grep -r --include='*.java' Holder
  java/org/gnu/emacs/EmacsService.java:class Holder<T>
  java/org/gnu/emacs/EmacsService.java:    final Holder<EmacsView> view;
  java/org/gnu/emacs/EmacsService.java:    view = new Holder<EmacsView> ();
  java/org/gnu/emacs/EmacsService.java:    final Holder<ClipboardManager> manager;
  java/org/gnu/emacs/EmacsService.java:    manager = new Holder<ClipboardManager> ();
  java/org/gnu/emacs/EmacsDialog.java:    final Holder<Boolean> rc;
  java/org/gnu/emacs/EmacsDialog.java:    rc = new Holder<Boolean> ();
  java/org/gnu/emacs/EmacsContextMenu.java:    final Holder<Boolean> rc;
  java/org/gnu/emacs/EmacsContextMenu.java:    rc = new Holder<Boolean> ();

There is no dependency between these Holder<T> users and the .java that
provides it:

  ~/gnu/emacs-android2/java$ rm org/gnu/emacs/EmacsDialog.class
  ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
    JAVAC    org/gnu/emacs/EmacsDialog.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  org/gnu/emacs/EmacsDialog.java:302: error: cannot find symbol
      final Holder<Boolean> rc;
            ^
    symbol:   class Holder
    location: class EmacsDialog
  org/gnu/emacs/EmacsDialog.java:304: error: cannot find symbol
      rc = new Holder<Boolean> ();
               ^
    symbol:   class Holder
    location: class EmacsDialog
  2 errors
  4 warnings
  make: *** [Makefile:261: org/gnu/emacs/EmacsDialog.class] Error 1
  ~/gnu/emacs-android2/java 2 $ rm org/gnu/emacs/EmacsService.class; make org/gnu/emacs/EmacsService.class
    JAVAC    org/gnu/emacs/EmacsService.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  4 warnings
  ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
    JAVAC    org/gnu/emacs/EmacsDialog.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  4 warnings
  ~/gnu/emacs-android2/java$ 

The simplest way to fix it is probably to break out Holder<T> into
Holder.java, as that won't require manually bookkeeping the
dependencies.  I attached a patch, which builds on x86_64-pc-linux-gnu.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: [PATCH] java: Resolve possible parallelism error across Holder class --]
[-- Type: text/x-patch, Size: 1333 bytes --]

From faf8fc54ad1d835d843e33833715eed2af83d517 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= <arsen@aarsen.me>
Date: Sun, 19 Feb 2023 16:21:02 +0100
Subject: [PATCH] java: Resolve possible parallelism error across Holder class

* java/org/gnu/emacs/EmacsService.java (Holder): Move from here
to...
* java/org/gnu/emacs/Holder.java: ... here.  New file.
---
 java/org/gnu/emacs/EmacsService.java | 5 -----
 java/org/gnu/emacs/Holder.java       | 6 ++++++
 2 files changed, 6 insertions(+), 5 deletions(-)
 create mode 100644 java/org/gnu/emacs/Holder.java

diff --git a/java/org/gnu/emacs/EmacsService.java b/java/org/gnu/emacs/EmacsService.java
index ba6ec485d62..18cbb06eaa8 100644
--- a/java/org/gnu/emacs/EmacsService.java
+++ b/java/org/gnu/emacs/EmacsService.java
@@ -62,11 +62,6 @@
 
 import android.hardware.input.InputManager;
 
-class Holder<T>
-{
-  T thing;
-};
-
 /* EmacsService is the service that starts the thread running Emacs
    and handles requests by that Emacs instance.  */
 
diff --git a/java/org/gnu/emacs/Holder.java b/java/org/gnu/emacs/Holder.java
new file mode 100644
index 00000000000..41866084ab9
--- /dev/null
+++ b/java/org/gnu/emacs/Holder.java
@@ -0,0 +1,6 @@
+package org.gnu.emacs;
+
+class Holder<T>
+{
+  T thing;
+};
-- 
2.39.2


[-- Attachment #1.3: Type: text/plain, Size: 149 bytes --]


I also tested the above by making EmacsDialog.class on a clean
configure, triggering the edge case.

Thanks in advance.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Hi,
>
> I encountered another one:
>
>   javac -classpath "/home/arsen/Android/Sdk/platforms/android-Tiramisu/android.jar:." -target 1.7 -source 1.7 -Xlint:d
>   eprecation org/gnu/emacs/EmacsContextMenu.java
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   org/gnu/emacs/EmacsContextMenu.java:265: error: cannot find symbol
>       final Holder<Boolean> rc;
>             ^
>     symbol:   class Holder
>     location: class EmacsContextMenu
>   org/gnu/emacs/EmacsContextMenu.java:267: error: cannot find symbol
>       rc = new Holder<Boolean> ();
>                ^
>     symbol:   class Holder
>     location: class EmacsContextMenu
>   2 errors
>   4 warnings
>   make[2]: *** [Makefile:261: org/gnu/emacs/EmacsContextMenu.class] Error 1 shuffle=2758590628
>
> I tried replicating with that shuffle= value, but it seems that I did
> not get lucky twice.  However, I believe I have the reason why:
>
>   ~/gnu/emacs-android2 130 $ grep -r --include='*.java' Holder
>   java/org/gnu/emacs/EmacsService.java:class Holder<T>
>   java/org/gnu/emacs/EmacsService.java:    final Holder<EmacsView> view;
>   java/org/gnu/emacs/EmacsService.java:    view = new Holder<EmacsView> ();
>   java/org/gnu/emacs/EmacsService.java:    final Holder<ClipboardManager> manager;
>   java/org/gnu/emacs/EmacsService.java:    manager = new Holder<ClipboardManager> ();
>   java/org/gnu/emacs/EmacsDialog.java:    final Holder<Boolean> rc;
>   java/org/gnu/emacs/EmacsDialog.java:    rc = new Holder<Boolean> ();
>   java/org/gnu/emacs/EmacsContextMenu.java:    final Holder<Boolean> rc;
>   java/org/gnu/emacs/EmacsContextMenu.java:    rc = new Holder<Boolean> ();
>
> There is no dependency between these Holder<T> users and the .java that
> provides it:
>
>   ~/gnu/emacs-android2/java$ rm org/gnu/emacs/EmacsDialog.class
>   ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
>     JAVAC    org/gnu/emacs/EmacsDialog.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   org/gnu/emacs/EmacsDialog.java:302: error: cannot find symbol
>       final Holder<Boolean> rc;
>             ^
>     symbol:   class Holder
>     location: class EmacsDialog
>   org/gnu/emacs/EmacsDialog.java:304: error: cannot find symbol
>       rc = new Holder<Boolean> ();
>                ^
>     symbol:   class Holder
>     location: class EmacsDialog
>   2 errors
>   4 warnings
>   make: *** [Makefile:261: org/gnu/emacs/EmacsDialog.class] Error 1
>   ~/gnu/emacs-android2/java 2 $ rm org/gnu/emacs/EmacsService.class; make org/gnu/emacs/EmacsService.class
>     JAVAC    org/gnu/emacs/EmacsService.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   4 warnings
>   ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
>     JAVAC    org/gnu/emacs/EmacsDialog.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   4 warnings
>   ~/gnu/emacs-android2/java$ 
>
> The simplest way to fix it is probably to break out Holder<T> into
> Holder.java, as that won't require manually bookkeeping the
> dependencies.  I attached a patch, which builds on x86_64-pc-linux-gnu.
>
> From faf8fc54ad1d835d843e33833715eed2af83d517 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= <arsen@aarsen.me>
> Date: Sun, 19 Feb 2023 16:21:02 +0100
> Subject: [PATCH] java: Resolve possible parallelism error across Holder class
>
> * java/org/gnu/emacs/EmacsService.java (Holder): Move from here
> to...
> * java/org/gnu/emacs/Holder.java: ... here.  New file.
> ---
>  java/org/gnu/emacs/EmacsService.java | 5 -----
>  java/org/gnu/emacs/Holder.java       | 6 ++++++
>  2 files changed, 6 insertions(+), 5 deletions(-)
>  create mode 100644 java/org/gnu/emacs/Holder.java
>
> diff --git a/java/org/gnu/emacs/EmacsService.java b/java/org/gnu/emacs/EmacsService.java
> index ba6ec485d62..18cbb06eaa8 100644
> --- a/java/org/gnu/emacs/EmacsService.java
> +++ b/java/org/gnu/emacs/EmacsService.java
> @@ -62,11 +62,6 @@
>  
>  import android.hardware.input.InputManager;
>  
> -class Holder<T>
> -{
> -  T thing;
> -};
> -
>  /* EmacsService is the service that starts the thread running Emacs
>     and handles requests by that Emacs instance.  */
>  
> diff --git a/java/org/gnu/emacs/Holder.java b/java/org/gnu/emacs/Holder.java
> new file mode 100644
> index 00000000000..41866084ab9
> --- /dev/null
> +++ b/java/org/gnu/emacs/Holder.java
> @@ -0,0 +1,6 @@
> +package org.gnu.emacs;
> +
> +class Holder<T>
> +{
> +  T thing;
> +};
> -- 
> 2.39.2
>
>
> I also tested the above by making EmacsDialog.class on a clean
> configure, triggering the edge case.
>
> Thanks in advance.

Thanks.  The make depends thing is supposed to be done by javac
internally, and it should scan through source files in
org/gnu/emacs to find missing definitions.

I will try to fix the group rule definition.

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Hi Po,

Po Lu <luangruo@yahoo.com> writes:

> Thanks.  The make depends thing is supposed to be done by javac
> internally, and it should scan through source files in
> org/gnu/emacs to find missing definitions.

I believe it only scans through source files listed on the command line
and through the classpath.

> I will try to fix the group rule definition.

Yes, I believe this is the proper fix.  I was getting a bunch of other
errors in similar vein after fixing the one above, except even stranger,
so I suspect javac is quite bad at parallelizing.  The group build you
pushed earlier should alleviate that at a slight hit to compile speed
(which I doubt it's major enough to warrant build-time instability).

Thanks.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> Hi Po,
>
> Po Lu <luangruo@yahoo.com> writes:
>
>> Thanks.  The make depends thing is supposed to be done by javac
>> internally, and it should scan through source files in
>> org/gnu/emacs to find missing definitions.
>
> I believe it only scans through source files listed on the command line
> and through the classpath.

org/gnu/emacs is in the classpath.

> Yes, I believe this is the proper fix.  I was getting a bunch of other
> errors in similar vein after fixing the one above, except even stranger,
> so I suspect javac is quite bad at parallelizing.  The group build you
> pushed earlier should alleviate that at a slight hit to compile speed
> (which I doubt it's major enough to warrant build-time instability).

Thanks for finding this bug in javac.

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi Po,
>>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Thanks.  The make depends thing is supposed to be done by javac
>>> internally, and it should scan through source files in
>>> org/gnu/emacs to find missing definitions.
>>
>> I believe it only scans through source files listed on the command line
>> and through the classpath.
>
> org/gnu/emacs is in the classpath.

Yes, and the sourcepath too, but I don't think the sources in those
paths are re-parsed to grab class definitions on each build, which is
where the problem stems for, but are instead parsed on an as needed
basis, with the classes available being presumed to map 1-to-1 to the
list of .java files in the sourcepath.

>> Yes, I believe this is the proper fix.  I was getting a bunch of other
>> errors in similar vein after fixing the one above, except even stranger,
>> so I suspect javac is quite bad at parallelizing.  The group build you
>> pushed earlier should alleviate that at a slight hit to compile speed
>> (which I doubt it's major enough to warrant build-time instability).
>
> Thanks for finding this bug in javac.

Sure, if you end up reporting it, please keep me posted.  I'm curious
about what the intended behavior here is.

Thanks.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi,
>>
>> While building initially, I got some make errors that looked like they
>> were from a race, for example:
>>
>>     GEN         execinfo.h
>>   mv: cannot stat 'execinfo.h-t': No such file or directory
>>
>> Further confirming my suspicion that these are coming from a race is
>> Emacs compiling fine if make is reinvoked, and that a non-parallel make
>> build works fine.
>>
>> I figured this was a fluke initially, but, I reproduced the issue today.
>> You can fetch the build log from here:
>> https://www.aarsen.me/~arsen/emacs-races.script
>>
>> There also appears to be a dependency missing between generating the APK
>> and running the pdumper, or such, since I could re-run make after make
>> concluded in the nonparallel case.
>
> This should not be a problem, since the dumping happens on-device on
> Android.

Ah, OK.

>> This seems pretty reproducible on my machine, I suspect due to the large
>> number of -t files utilized in Gnulib.
>
> I will look into this, thanks.
>
>> While I'm around, I was also thinking about how to enable using the
>> modifier keys on virtual keyboards without modifiers.  I was considering
>> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
>> held in combination with another key, hence, the sequence Press VolDown,
>> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
>> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
>> that I know rely on external tools (XKB configs, AHK, ...) that are not
>> available on android.
>
> I'm not sure how to do this, since those keys are not ``meta modifiers''
> on the system.
>
> I'd recommend an on screen keyboard which has those modifier keys
> instead.

Indeed, that'd require some state tracking, for instance, on press reset
a special-as-ctrl flag and set a special-held flag, if anything else is
typed interpret it as C-<N> if special-held is set and set
special-as-ctrl, and on key release, reset special-held and emit an ESC
if special-as-ctrl is reset.

I'm not aware of a better solution because, as you said, these keys
aren't modifiers, and register as normal keypresses.

My thinking here is that providing an alternative for folk who don't use
virtual keyboards with modifier keys already (which is, most likely,
almost everyone) could ease their transition and help them with muscle
memory.

Have a splendid day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port

[tomas]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Fri, Feb 17, 2023 at 07:51:42PM +0800, Po Lu wrote:
> I believe the Android port of Emacs is now more or less feature
> complete.

Not an Android user here, but: this is huge. Thanks a lot!

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I believe the Android port of Emacs is now more or less feature
> complete.
>
> It can be found on the feature/android branch of the Emacs repository,
> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
> Android devices capable of running Android 2.2 or later.  You can obtain
> a check out of that code like so:
>
>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>
> Please give it as much testing as you can on real hardware from many
> different Android vendors.  Follow the instructions in INSTALL.android
> to build and install Emacs for your specific device.  In addition,
> please submit patches and report editing modes that do not work well
> with the input methods of various on screen keyboards, along with other
> bugs, using ``M-x report-emacs-bug RET.''
>
> The answers to various common questions (such as ``how to access
> external storage'', or ``where does Emacs put its init.el'') are in the
> Android appendix of the Emacs manual in the branch.
>
> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.
>
> I will post this news to comp.emacs; please post this to other forums
> frequented by Emacs users as well.

A prebuilt binary for 64-bit ARM devices running Android 5.1 or later
can be found at:

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/files

Note that because F-Droid chose to sign their release with their own
signing key, you will have to uninstall the F-Droid version before
installing this one.

Re: Android port

[Etienne Prud'homme]

Sorry for the late reply.

Does this port allow Emacs to access files outside app-specific
storage?  When trying the Sourceforge build, I was unable to access
files outside `/data/data/org.gnu.emacs`.  It looks to me the
application doesn't ask for any storage permissions.

Trying to use it with no a touch keyboard is not really efficient for
me (yet), but I didn't see any functions that would ask Android to
allow file system access.

I was surprised to see so many things working.  Thanks for your work.

Etienne Prud'homme

Re: Android port

[Po Lu]

"Etienne Prud'homme" <e.e.f.prudhomme@gmail.com> writes:

> Sorry for the late reply.
>
> Does this port allow Emacs to access files outside app-specific
> storage?  When trying the Sourceforge build, I was unable to access
> files outside `/data/data/org.gnu.emacs`.  It looks to me the
> application doesn't ask for any storage permissions.
>
> I was surprised to see so many things working.  Thanks for your work.
>
> Etienne Prud'homme

Emacs does not ask for any permissions by default.  You must enable
access to storage on Android 10 and earlier, and access to ``All files
and media'' on Android 11 and later.  This is described in the Android
appendix of the Emacs manual, which I suggest you read.

> Trying to use it with no a touch keyboard is not really efficient for
> me (yet), but I didn't see any functions that would ask Android to
> allow file system access.

Why is that?
The on-screen keyboard should be displayed whenever necessary.

Thanks.

gnulib fsusage

[Po Lu]

Apparently lib/fsusage.o is not built when there is no suitable way for
it to get the necessary information, but it is still used
unconditionally by Emacs.

Is this the right way to detect whether or not get_fs_usage is actually
present?

diff --git a/src/fileio.c b/src/fileio.c
index 6fa524b3bb4..87d7e901203 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -6360,6 +6360,10 @@ DEFUN ("file-system-info", Ffile_system_info, Sfile_system_info, 1, 1, 0,
       error ("Invalid handler in `file-name-handler-alist'");
     }
 
+#if defined STAT_STATFS2_BSIZE || defined STAT_STATFS2_FRSIZE	\
+  || defined STAT_STATFS2_FSIZE || defined STAT_STATFS3_OSF1	\
+  || defined STAT_STATFS4 || defined STAT_STATVFS		\
+  || defined STAT_STATVFS64
   struct fs_usage u;
   if (get_fs_usage (SSDATA (ENCODE_FILE (filename)), NULL, &u) != 0)
     return errno == ENOSYS ? Qnil : file_attribute_errno (filename, errno);
@@ -6367,6 +6371,9 @@ DEFUN ("file-system-info", Ffile_system_info, Sfile_system_info, 1, 1, 0,
 		blocks_to_bytes (u.fsu_blocksize, u.fsu_bfree, false),
 		blocks_to_bytes (u.fsu_blocksize, u.fsu_bavail,
 				 u.fsu_bavail_top_bit_set));
+#else
+  return Qnil;
+#endif
 }
 
 #endif /* !DOS_NT */

It's probably not, but I don't have any better ideas.

Thanks.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Thu, 19 Jan 2023 10:24:29 +0800
> 
> Apparently lib/fsusage.o is not built when there is no suitable way for
> it to get the necessary information, but it is still used
> unconditionally by Emacs.

Not unconditionally: the implementation of file-system-info in
fileio.c is conditioned on !DOS_NT, and both MSDOS and WINDOWSNT ports
have their separate implementations which don't use Gnulib's fsusage.

> Is this the right way to detect whether or not get_fs_usage is actually
> present?

Which port needs to exclude it, and why?  Is that port going to
implement its own version of file-system-info?  We must have a
non-trivial working implementation for each supported platform,
because Dired (and Tramp?) uses it.

If the port you are considering will have its own implementation, then
the same method as DOS_NT uses will be appropriate.

> +#else
> +  return Qnil;
> +#endif

I don't think this could fly, because Dired and other places need a
real implementation.  Please tell more about the problem you are
trying to solve.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Date: Thu, 19 Jan 2023 10:24:29 +0800
>> 
>> Apparently lib/fsusage.o is not built when there is no suitable way for
>> it to get the necessary information, but it is still used
>> unconditionally by Emacs.
>
> Not unconditionally: the implementation of file-system-info in
> fileio.c is conditioned on !DOS_NT, and both MSDOS and WINDOWSNT ports
> have their separate implementations which don't use Gnulib's fsusage.
>
>> Is this the right way to detect whether or not get_fs_usage is actually
>> present?
>
> Which port needs to exclude it, and why?  Is that port going to
> implement its own version of file-system-info?  We must have a
> non-trivial working implementation for each supported platform,
> because Dired (and Tramp?) uses it.

The Android port doesn't support statvfs, because that function is
missing from the Android C library, apparently for security reasons.

> If the port you are considering will have its own implementation, then
> the same method as DOS_NT uses will be appropriate.

I cannot find any way to do such an implementation, sorry.  But if
someone else knows, that would be great.  Thanks.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 18:11:45 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which port needs to exclude it, and why?  Is that port going to
> > implement its own version of file-system-info?  We must have a
> > non-trivial working implementation for each supported platform,
> > because Dired (and Tramp?) uses it.
> 
> The Android port doesn't support statvfs, because that function is
> missing from the Android C library, apparently for security reasons.

Don't you think your work on the Android port should be discussed
more, and not just for the current minor issue?  I'd hate to have
those discussions when the port is ready, which means you will have
invested a lot of hard labor in it.

> > If the port you are considering will have its own implementation, then
> > the same method as DOS_NT uses will be appropriate.
> 
> I cannot find any way to do such an implementation, sorry.  But if
> someone else knows, that would be great.  Thanks.

At least return a list of 3 numbers (zeros?), not nil.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Don't you think your work on the Android port should be discussed
> more, and not just for the current minor issue?  I'd hate to have
> those discussions when the port is ready, which means you will have
> invested a lot of hard labor in it.

Well, I only just found out this problem, and have immediately begun
discussing it.  Isn't that fast enough? :D

> At least return a list of 3 numbers (zeros?), not nil.

OK.  But the doc string says it can return nil if the system call fails.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 19:59:54 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Don't you think your work on the Android port should be discussed
> > more, and not just for the current minor issue?  I'd hate to have
> > those discussions when the port is ready, which means you will have
> > invested a lot of hard labor in it.
> 
> Well, I only just found out this problem, and have immediately begun
> discussing it.  Isn't that fast enough? :D

I didn't just read your request, I've looked at the branch.  I'm not
sure I'm happy with what I see there.  Too much stuff that IMNSHO
should have been discussed before coding it.

> > At least return a list of 3 numbers (zeros?), not nil.
> 
> OK.  But the doc string says it can return nil if the system call fails.

<Shrug> Suit yourself.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't just read your request, I've looked at the branch.  I'm not
> sure I'm happy with what I see there.  Too much stuff that IMNSHO
> should have been discussed before coding it.

Could you please explain what that would be?
This seems like a good opportunity to start discussing it now, thanks.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 21:40:18 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I didn't just read your request, I've looked at the branch.  I'm not
> > sure I'm happy with what I see there.  Too much stuff that IMNSHO
> > should have been discussed before coding it.
> 
> Could you please explain what that would be?
> This seems like a good opportunity to start discussing it now, thanks.

First, we need to decide whether we indeed want to have this in Emacs.
Android is not a free platform, so when its support comes with a lot
of additional non-trivial code that we'd need to understand and
support/maintain (including a lot of Java), we had better discussed
that first.

If we do decide to have this, I'd definitely want more documentation
of the internals and how they differ from the "traditional" platforms
than you have there now, and preferably in one place, not scattered
among the many source files, Makefile's, and READMEs.

Then there are the design decisions you made: how to support windows
and frames, how to handle the "task-killer" issues, how to handle the
Android's access rights and privileges system, etc.  For instance, I
was quite surprised to see lack of support for scroll bars on account
of them being "useless": I'm a happy user of an Android smartphone,
and I use the scroll bars all the time.

If we are to have a serious discussion of this, I'd encourage people
to read the code of the branch and bring up issues here.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> First, we need to decide whether we indeed want to have this in Emacs.
> Android is not a free platform, so when its support comes with a lot
> of additional non-trivial code that we'd need to understand and
> support/maintain (including a lot of Java), we had better discussed
> that first.

OK.  But to be fair, I had zero experience with Android development
myself before working on this; I have taken care to keep the Java code
as minimal as possible and comprehensible to C developers.

> If we do decide to have this, I'd definitely want more documentation
> of the internals and how they differ from the "traditional" platforms
> than you have there now, and preferably in one place, not scattered
> among the many source files, Makefile's, and READMEs.

Sure.  Please feel free to describe what you find confusing, and I will
try to document it in the README in the java directory.

> Then there are the design decisions you made: how to support windows
> and frames, how to handle the "task-killer" issues, how to handle the
> Android's access rights and privileges system, etc.

> For instance, I was quite surprised to see lack of support for scroll
> bars on account of them being "useless": I'm a happy user of an
> Android smartphone, and I use the scroll bars all the time.

I tried to find the scroll bars in a real (as in, not Emacs) Android
application, and could not find any at all.  The scroll bar in the
toolkit does not respond to input at all, and disappears after you
finish scrolling.  Besides, the Emacs scroll bar implementation I worked
on had major problems adapting to touch screen input.

> If we are to have a serious discussion of this, I'd encourage people
> to read the code of the branch and bring up issues here.

Yes, please do so.  Thanks.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 22:34:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we do decide to have this, I'd definitely want more documentation
> > of the internals and how they differ from the "traditional" platforms
> > than you have there now, and preferably in one place, not scattered
> > among the many source files, Makefile's, and READMEs.
> 
> Sure.  Please feel free to describe what you find confusing, and I will
> try to document it in the README in the java directory.

It isn't just about the Java directory.  It's every point where the
Android port deviates from its desktop/laptop behavior.  Starting with
dumping, then the fact that we compile to shared libraries instead of
executables, etc. etc.

> > Then there are the design decisions you made: how to support windows
> > and frames, how to handle the "task-killer" issues, how to handle the
> > Android's access rights and privileges system, etc.
> 
> > For instance, I was quite surprised to see lack of support for scroll
> > bars on account of them being "useless": I'm a happy user of an
> > Android smartphone, and I use the scroll bars all the time.
> 
> I tried to find the scroll bars in a real (as in, not Emacs) Android
> application, and could not find any at all.

?? The Web browser comes to mind and the email client.  The scroll bar
in both is quite functional.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> It isn't just about the Java directory.  It's every point where the
> Android port deviates from its desktop/laptop behavior.  Starting with
> dumping, then the fact that we compile to shared libraries instead of
> executables, etc. etc.

Where should that information be put?

> ?? The Web browser comes to mind and the email client.  The scroll bar
> in both is quite functional.

Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
K9 mail does have them, but of the disappearing kind.  What vendor made
your Android device?

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 20 Jan 2023 08:18:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It isn't just about the Java directory.  It's every point where the
> > Android port deviates from its desktop/laptop behavior.  Starting with
> > dumping, then the fact that we compile to shared libraries instead of
> > executables, etc. etc.
> 
> Where should that information be put?

Preferably on the android_*.c files, each file with its part of the
story.  Alternatively, you could have a separate android-internals.txt
file in admin/notes/, I suppose.

> > ?? The Web browser comes to mind and the email client.  The scroll bar
> > in both is quite functional.
> 
> Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
> K9 mail does have them, but of the disappearing kind.  What vendor made
> your Android device?

Samsung.  I tried their own browser (which AFAIU is a derivative of
Chromium), not Firefox.

It sounds like on Android, scroll bars are not unified, and each app
provides what it wants.  But it is definitely possible to have a
functional scroll bar.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Preferably on the android_*.c files, each file with its part of the
> story.  Alternatively, you could have a separate android-internals.txt
> file in admin/notes/, I suppose.

OK, thanks.  I think the latter would be easier.

>> > ?? The Web browser comes to mind and the email client.  The scroll bar
>> > in both is quite functional.
>> 
>> Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
>> K9 mail does have them, but of the disappearing kind.  What vendor made
>> your Android device?
>
> Samsung.  I tried their own browser (which AFAIU is a derivative of
> Chromium), not Firefox.

Thanks.  I'll take a look at what the Samsung browser does.

> It sounds like on Android, scroll bars are not unified, and each app
> provides what it wants.  But it is definitely possible to have a
> functional scroll bar.

I guess so.  The non-functional scroll bar I was referring to is the
scroll bar provided by the Android toolkit as part of the ScrollView
widget.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Preferably on the android_*.c files, each file with its part of the
> story.  Alternatively, you could have a separate android-internals.txt
> file in admin/notes/, I suppose.

I ended up putting a significant writeup in java/README, as that's where
the Nextstep port has its documentation, which is supposed to teach us
Emacs developers Objective-C.

Would you please read it and say what you think?
I will extend it in the next few days to describe more of the GUI code
as well.

Thanks.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 25 Jan 2023 18:48:05 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Preferably on the android_*.c files, each file with its part of the
> > story.  Alternatively, you could have a separate android-internals.txt
> > file in admin/notes/, I suppose.
> 
> I ended up putting a significant writeup in java/README, as that's where
> the Nextstep port has its documentation, which is supposed to teach us
> Emacs developers Objective-C.
> 
> Would you please read it and say what you think?

Thanks, will do when I have time.

Re: Android port (was: gnulib fsusage)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: emacs-devel@gnu.org
> > Date: Thu, 19 Jan 2023 21:40:18 +0800
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > I didn't just read your request, I've looked at the branch.  I'm not
> > > sure I'm happy with what I see there.  Too much stuff that IMNSHO
> > > should have been discussed before coding it.
> > 
> > Could you please explain what that would be?
> > This seems like a good opportunity to start discussing it now, thanks.
> 
> First, we need to decide whether we indeed want to have this in Emacs.
> Android is not a free platform, so when its support comes with a lot
> of additional non-trivial code that we'd need to understand and
> support/maintain (including a lot of Java), we had better discussed
> that first.

Replicant is free platform.

Replicant:
https://www.replicant.us/

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> Date: Fri, 20 Jan 2023 09:47:34 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > First, we need to decide whether we indeed want to have this in Emacs.
> > Android is not a free platform, so when its support comes with a lot
> > of additional non-trivial code that we'd need to understand and
> > support/maintain (including a lot of Java), we had better discussed
> > that first.
> 
> Replicant is free platform.

That fact is not relevant to this discussion.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > First, we need to decide whether we indeed want to have this in Emacs.
> > > Android is not a free platform, so when its support comes with a lot
> > > of additional non-trivial code that we'd need to understand and
> > > support/maintain (including a lot of Java), we had better discussed
> > > that first.
> > 
> > Replicant is free platform.
> 
> That fact is not relevant to this discussion.

I think the point Jean meant to make is that Android platform per se isn't
closed, even if the unfortunate situation is that many vendors ship a lot of
closed code, mainly drivers (tho situation with closed drivers is slowly
improving, Google seem to be working on that).

The link Jean posted is just one of (free and open source) derivatives of
Android platform. The other one very popular comes to mind was CyanogenMod,
which later was succeeded by LineageOS.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 28 Jan 2023 10:50:02 +0300
> 
> On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > 
> > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > Android is not a free platform, so when its support comes with a lot
> > > > of additional non-trivial code that we'd need to understand and
> > > > support/maintain (including a lot of Java), we had better discussed
> > > > that first.
> > > 
> > > Replicant is free platform.
> > 
> > That fact is not relevant to this discussion.
> 
> I think the point Jean meant to make is that Android platform per se isn't
> closed, even if the unfortunate situation is that many vendors ship a lot of
> closed code, mainly drivers (tho situation with closed drivers is slowly
> improving, Google seem to be working on that).
> 
> The link Jean posted is just one of (free and open source) derivatives of
> Android platform. The other one very popular comes to mind was CyanogenMod,
> which later was succeeded by LineageOS.

Since the absolute majority of Android devices out there are non-free,
the fact that a small number of free ones exist is not relevant to
the main points of this discussion.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 10:49 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sat, 28 Jan 2023 10:50:02 +0300
> > 
> > On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > > 
> > > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > > Android is not a free platform, so when its support comes with a lot
> > > > > of additional non-trivial code that we'd need to understand and
> > > > > support/maintain (including a lot of Java), we had better discussed
> > > > > that first.
> > > > 
> > > > Replicant is free platform.
> > > 
> > > That fact is not relevant to this discussion.
> > 
> > I think the point Jean meant to make is that Android platform per se isn't
> > closed, even if the unfortunate situation is that many vendors ship a lot of
> > closed code, mainly drivers (tho situation with closed drivers is slowly
> > improving, Google seem to be working on that).
> > 
> > The link Jean posted is just one of (free and open source) derivatives of
> > Android platform. The other one very popular comes to mind was CyanogenMod,
> > which later was succeeded by LineageOS.
> 
> Since the absolute majority of Android devices out there are non-free,
> the fact that a small number of free ones exist is not relevant to
> the main points of this discussion.

You seem to be confusing a platform per se with customer devices it installed on. The Android platform is free: it has its sources open, it is being developed in the open, and it even has derivatives.

The unfortunate fact that majority of the customer devices has a *modified* Android where the modifications were not released in the public is in my opinion irrelevant. That is because you are not developing against specific proprietary device, instead you are developing against open Android libraries, which are supported by those devices anyway.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: bugs@gnu.support, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 28 Jan 2023 12:06:02 +0300
> 
> > Since the absolute majority of Android devices out there are non-free,
> > the fact that a small number of free ones exist is not relevant to
> > the main points of this discussion.
> 
> You seem to be confusing a platform per se with customer devices it installed on. The Android platform is free: it has its sources open, it is being developed in the open, and it even has derivatives.

AFAIK, even this part is not true: most Android devices have custom
proprietary additions and changes to the platform specific to each
vendor.

> The unfortunate fact that majority of the customer devices has a *modified* Android where the modifications were not released in the public is in my opinion irrelevant. That is because you are not developing against specific proprietary device, instead you are developing against open Android libraries, which are supported by those devices anyway.

I don't see how this is relevant, sorry.  The platform is still
non-free, and the fact that it started from free baseline doesn't
matter.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 11:21 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: bugs@gnu.support, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sat, 28 Jan 2023 12:06:02 +0300
> > 
> > > Since the absolute majority of Android devices out there are non-free,
> > > the fact that a small number of free ones exist is not relevant to
> > > the main points of this discussion.
> > 
> > You seem to be confusing a platform per se with customer devices it
> > installed on. The Android platform is free: it has its sources open, it is
> > being developed in the open, and it even has derivatives.
> 
> AFAIK, even this part is not true: most Android devices have custom
> proprietary additions and changes to the platform specific to each
> vendor.

Please don't generalize actions of individual companies to the platform as whole. Your reply doesn't make my statement false, because the original Android is the one where no such vendor additions were made.

Either way, I doubt Po is planning to make any use of such proprietary additions, so discussing those additions has no value.

Re: Android port

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Please don't generalize actions of individual companies to the platform as whole. Your reply doesn't make my statement false, because the original Android is the one where no such vendor additions were made.
>
> Either way, I doubt Po is planning to make any use of such proprietary
> additions, so discussing those additions has no value.

We are not going to use features only in proprietary versions of Android
because we hope that the resulting Emacs binaries will also work on free
operating systems such as AOSP and Replicant.

But Android itself is proprietary from a practical standpoint, so we
will continue to treat it as a proprietary platform wrt its support in
Emacs, if only because free Android is available for a minuscule amount
of users.

Re: Android port

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
>> > Date: Fri, 20 Jan 2023 09:47:34 +0300
>> > From: Jean Louis <bugs@gnu.support>
>> > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
>> > 
>> > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
>> > > First, we need to decide whether we indeed want to have this in Emacs.
>> > > Android is not a free platform, so when its support comes with a lot
>> > > of additional non-trivial code that we'd need to understand and
>> > > support/maintain (including a lot of Java), we had better discussed
>> > > that first.
>> > 
>> > Replicant is free platform.
>> 
>> That fact is not relevant to this discussion.
>
> I think the point Jean meant to make is that Android platform per se isn't
> closed, even if the unfortunate situation is that many vendors ship a lot of
> closed code, mainly drivers (tho situation with closed drivers is slowly
> improving, Google seem to be working on that).

Google is working on allowing the proprietary drivers to run alongside
any version of Linux, not on removing them entirely.

Google themselves develop Play Services, arguably the most problematic
piece of proprietary software in Android.

> The link Jean posted is just one of (free and open source) derivatives of
> Android platform. The other one very popular comes to mind was CyanogenMod,
> which later was succeeded by LineageOS.

LineageOS and CyanogenMod are not free software, because both contain
proprietary device driver files, and in the case of CyanogenMod,
proprietary user level libraries as well.

AOSP, on the other hand, is really free software.  But that doesn't help
when you can only run it in an emulator.

If you had read the Android appendix of the Emacs manual, you would have
seen that it explains this situation:

H.1 Android history
===================

Android is an operating system for mobile devices developed by the Open
Handset Alliance, a group of companies interested in developing handsets
that can run a common set of software.  It is supposedly free software.

   Like the X Consortium of times past, the Open Handset Alliance
believes that “openness” (namely, the regular release of the Android
source code) is simply a tool to increase the popularity of the Android
platform.  Computer companies normally produce proprietary software.
The companies in the Open Handset Alliance are no different – most
versions of Android installed on devices are proprietary, by virtue of
containing proprietary components, that often cannot even be replaced by
the user.

   Android is not designed to respect users’ freedom.  Almost all
versions of Android (including some which are supposedly free software)
include support for Digital Restrictions Management, technology that is
designed to limit users’ ability to copy media to and from their own
devices.  Most Android devices also come with proprietary Google
applications which are required to run the system, and many other
Android applications.

   Thus, it must be necessary to consider Android proprietary software
from a practical standpoint.  That is an injustice.  If you use Android,
we urge you to switch to a free operating system, if only for your
freedom’s sake.

   We support GNU Emacs on proprietary operating systems because we hope
this taste of freedom will inspire users to escape from them.

Re: Android port

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 17:57 +0800, Po Lu wrote:
> Google is working on allowing the proprietary drivers to run alongside
> any version of Linux, not on removing them entirely.
> 
> Google themselves develop Play Services, arguably the most problematic
> piece of proprietary software in Android.
> 
> > The link Jean posted is just one of (free and open source) derivatives of
> > Android platform. The other one very popular comes to mind was CyanogenMod,
> > which later was succeeded by LineageOS.
> 
> LineageOS and CyanogenMod are not free software, because both contain
> proprietary device driver files, and in the case of CyanogenMod,
> proprietary user level libraries as well.
> 
> AOSP, on the other hand, is really free software.  But that doesn't help
> when you can only run it in an emulator.
> 
> If you had read the Android appendix of the Emacs manual, you would have
> seen that it explains this situation:

I didn't because a link to the branch was never posted in the thread ☺

Either way, now I see the point you are trying to make as you're using an
expression "from a practical standpoint it is closed". So, like, in theory it is
open, but in practice no device runs the original Android.

In my head I still can't connect the relevance of that "practice" to Emacs
Android  port though, because you can treat the port as a program that is
supposed to run on the original open platform, and then, almost "accidentally"
(not really, but I hope you see my point), as an app that can run on any other
Android device…

But I won't be going into that further because my main motivation for
participation was to make sure your work on making the port isn't wasted, which,
judging by your reply, seem to have been resolved before I joined.

So, anyway, thanks for your work!