Warnings during building the current master on Win10 with MSYS2/MinGW64

Warnings during building the current master on Win10 with MSYS2/MinGW64

[Arash Esbati]

Hi all,

after a long time, I built Emacs (baf9f1210a) from master on my Win10
box and it occurred to me that I get more warnings than I used to.  This
is with

$ gcc --version
gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

It starts with (linebreaks added manually):

--8<---------------cut here---------------start------------->8---
boot-time-aux.h: In function 'get_windows_boot_time_fallback':
boot-time-aux.h:395:26: warning: the comparison will always evaluate as
                'true' for the address of 'GetTickCount64' will never be
                NULL [-Waddress]
  395 |   if (GetTickCount64Func != NULL)
      |                          ^~
In file included from C:/msys64/mingw64/include/winbase.h:36,
                 from C:/msys64/mingw64/include/windows.h:70,
                 from boot-time.c:48:
C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
   42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
      |                               ^~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

and goes on with:

--8<---------------cut here---------------start------------->8---
In file included from regex.c:69:
regex_internal.c: In function 'create_ci_newstate':
regex_internal.c:1599:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 1599 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
      |                                                ^~~~~~~~~~~~~
regex_internal.c:1599:48: note: earlier argument should specify number of elements, later size of each element
regex_internal.c: In function 'create_cd_newstate':
regex_internal.c:1647:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 1647 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
      |                                                ^~~~~~~~~~~~~
regex_internal.c:1647:48: note: earlier argument should specify number of elements, later size of each element
In file included from regex.c:70:
regcomp.c: In function 'init_dfa':
regcomp.c:834:38: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
  834 |   dfa->state_table = calloc (sizeof (struct re_state_table_entry), table_size);
      |                                      ^~~~~~
regcomp.c:834:38: note: earlier argument should specify number of elements, later size of each element
regcomp.c:865:60: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
  865 |           dfa->sb_char = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                                            ^~~~~~~~
regcomp.c:865:60: note: earlier argument should specify number of elements, later size of each element
regcomp.c: In function 'parse_bracket_exp':
regcomp.c:3058:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3058 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                              ^~~~~~~~
regcomp.c:3058:46: note: earlier argument should specify number of elements, later size of each element
regcomp.c:3059:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3059 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
      |                                             ^~~~~~~~~~~~
regcomp.c:3059:45: note: earlier argument should specify number of elements, later size of each element
regcomp.c: In function 'build_charclass_op':
regcomp.c:3551:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3551 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
      |                                              ^~~~~~~~
regcomp.c:3551:46: note: earlier argument should specify number of elements, later size of each element
regcomp.c:3557:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3557 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
      |                                             ^~~~~~~~~~~~
regcomp.c:3557:45: note: earlier argument should specify number of elements, later size of each element
In file included from regex.c:71:
regexec.c: In function 'get_subexp':
regexec.c:2724:47: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 2724 |               sub_top->path = calloc (sizeof (state_array_t),
      |                                               ^~~~~~~~~~~~~
regexec.c:2724:47: note: earlier argument should specify number of elements, later size of each element
regexec.c: In function 'build_trtable':
regexec.c:3269:29: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3269 |             calloc (sizeof (re_dfastate_t *), SBC_MAX);
      |                             ^~~~~~~~~~~~~
regexec.c:3269:29: note: earlier argument should specify number of elements, later size of each element
regexec.c:3341:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3341 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), SBC_MAX);
      |                                            ^~~~~~~~~~~~~
regexec.c:3341:44: note: earlier argument should specify number of elements, later size of each element
regexec.c:3372:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 3372 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), 2 * SBC_MAX);
      |                                            ^~~~~~~~~~~~~
regexec.c:3372:44: note: earlier argument should specify number of elements, later size of each element
--8<---------------cut here---------------end--------------->8---

And others.  Is there an interest to see them all, should I post them
here or to the bug tracker?

I build Emacs with a small script like this:

--8<---------------cut here---------------start------------->8---
git clean -fdx --exclude=ChangeLog
./autogen.sh &&              \
CPPFLAGS='-DNDEBUG'          \
CFLAGS='-O2 -g0 -pipe'       \
LDFLAGS='-s -Wl,-s'          \
./configure                  \
--host=x86_64-w64-mingw32    \
--target=x86_64-w64-mingw32  \
--build=x86_64-w64-mingw32   \
--with-jpeg                  \
--with-gif                   \
--with-xpm                   \
--with-png                   \
--with-tiff                  \
--with-rsvg                  \
--with-webp                  \
--with-sqlite3               \
--with-xml2                  \
--with-gnutls                \
--with-lcms2                 \
--with-modules               \
--with-threads               \
--with-native-compilation    \
--with-native-image-api      \
--with-tree-sitter           \
--with-xdbe                  \
--without-imagemagick        \
--without-dbus               \
--without-gconf              \
--without-gsettings          \
--without-compress-install   \
--without-mailutils          \
--without-pop  &&            \
make  ...
--8<---------------cut here---------------end--------------->8---

Best, Arash

Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> after a long time, I built Emacs (baf9f1210a) from master on my Win10
> box and it occurred to me that I get more warnings than I used to.  This
> is with
> 
> $ gcc --version
> gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

Sadly, the MS-Windows port of Emacs is basically not taken care of
anymore.  There are no active developers on board who seem to care
about it, except yours truly.  I see this in the (lack of) responses
to Windows-specific bugs and issues reported to the bug tracker: no
one chimes in, even if I deliberately leave a bug report without
responses for many days.  As my free time is severely limited, I only
care about aspects that affect me directly (and the 64-bit build and
GCC 14 are way outside that scope).

If no one comes forward and starts taking care of the MS-Windows
issues, I'm very close to the decision of declaring the Windows build
of Emacs "unsupported", meaning anyone who needs it are "on their
own", from my POV as the (co)maintainer.

This is not an April 1 joke: if there's a significant community
interested in being able to run and develop Emacs on MS-Windows,
someone should volunteer to take care of the build on a day to day
basis, or else the conclusion is that there's no general interest in
that platform among the Emacs community that is high enough to justify
the investment.

You _have_ been warned!

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> boot-time-aux.h: In function 'get_windows_boot_time_fallback':
> boot-time-aux.h:395:26: warning: the comparison will always evaluate as
>                 'true' for the address of 'GetTickCount64' will never be
>                 NULL [-Waddress]
>   395 |   if (GetTickCount64Func != NULL)
>       |                          ^~
> In file included from C:/msys64/mingw64/include/winbase.h:36,
>                  from C:/msys64/mingw64/include/windows.h:70,
>                  from boot-time.c:48:
> C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
>    42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
>       |                               ^~~~~~~~~~~~~~

This should be reported to Gnulib folks, not here, as it's Gnulib
code.  (The warning is bogus, of course.)

> In file included from regex.c:69:
> regex_internal.c: In function 'create_ci_newstate':
> regex_internal.c:1599:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  1599 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
>       |                                                ^~~~~~~~~~~~~
> regex_internal.c:1599:48: note: earlier argument should specify number of elements, later size of each element
> regex_internal.c: In function 'create_cd_newstate':
> regex_internal.c:1647:48: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  1647 |   newstate = (re_dfastate_t *) calloc (sizeof (re_dfastate_t), 1);
>       |                                                ^~~~~~~~~~~~~
> regex_internal.c:1647:48: note: earlier argument should specify number of elements, later size of each element
> In file included from regex.c:70:
> regcomp.c: In function 'init_dfa':
> regcomp.c:834:38: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>   834 |   dfa->state_table = calloc (sizeof (struct re_state_table_entry), table_size);
>       |                                      ^~~~~~
> regcomp.c:834:38: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:865:60: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>   865 |           dfa->sb_char = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                                            ^~~~~~~~
> regcomp.c:865:60: note: earlier argument should specify number of elements, later size of each element
> regcomp.c: In function 'parse_bracket_exp':
> regcomp.c:3058:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3058 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                              ^~~~~~~~
> regcomp.c:3058:46: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:3059:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3059 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
>       |                                             ^~~~~~~~~~~~
> regcomp.c:3059:45: note: earlier argument should specify number of elements, later size of each element
> regcomp.c: In function 'build_charclass_op':
> regcomp.c:3551:46: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3551 |   sbcset = (re_bitset_ptr_t) calloc (sizeof (bitset_t), 1);
>       |                                              ^~~~~~~~
> regcomp.c:3551:46: note: earlier argument should specify number of elements, later size of each element
> regcomp.c:3557:45: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3557 |   mbcset = (re_charset_t *) calloc (sizeof (re_charset_t), 1);
>       |                                             ^~~~~~~~~~~~
> regcomp.c:3557:45: note: earlier argument should specify number of elements, later size of each element
> In file included from regex.c:71:
> regexec.c: In function 'get_subexp':
> regexec.c:2724:47: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  2724 |               sub_top->path = calloc (sizeof (state_array_t),
>       |                                               ^~~~~~~~~~~~~
> regexec.c:2724:47: note: earlier argument should specify number of elements, later size of each element
> regexec.c: In function 'build_trtable':
> regexec.c:3269:29: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3269 |             calloc (sizeof (re_dfastate_t *), SBC_MAX);
>       |                             ^~~~~~~~~~~~~
> regexec.c:3269:29: note: earlier argument should specify number of elements, later size of each element
> regexec.c:3341:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3341 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), SBC_MAX);
>       |                                            ^~~~~~~~~~~~~
> regexec.c:3341:44: note: earlier argument should specify number of elements, later size of each element
> regexec.c:3372:44: warning: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
>  3372 |         (re_dfastate_t **) calloc (sizeof (re_dfastate_t *), 2 * SBC_MAX);
>       |                                            ^~~~~~~~~~~~~
> regexec.c:3372:44: note: earlier argument should specify number of elements, later size of each element
> --8<---------------cut here---------------end--------------->8---

These are all correct, but again, they are about Gnulib code and
should be reported to the Gnulib mailing list.

> And others.  Is there an interest to see them all, should I post them
> here or to the bug tracker?

If the warnings are for Emacs's own sources, please submit a bug
report.  Gnulib-related warnings should be reported to the Gnulib
mailing list.

Thanks.

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Collin Funk]

Eli Zaretskii <eliz@gnu.org> writes:

>> C:/msys64/mingw64/include/sysinfoapi.h:42:31: note: 'GetTickCount64' declared here
>>    42 |   WINBASEAPI ULONGLONG WINAPI GetTickCount64 (VOID);
>>       |                               ^~~~~~~~~~~~~~
>
> This should be reported to Gnulib folks, not here, as it's Gnulib
> code.  (The warning is bogus, of course.)

I agree that it is bogus. Most Gnulib Windows modules will have this
warning. The code is something like:

-----------------------------------------------
# if !(_WIN32_WINNT >= _WIN32_WINNT_VISTA)

/* GetTickCount64 is only available on Windows Vista and later.  */
typedef ULONGLONG (WINAPI * GetTickCount64FuncType) (void);

/* NULL if not loaded from the DLL, else a function pointer.  */
static GetTickCount64FuncType GetTickCount64Func = NULL;
static BOOL initialized = FALSE;

# else /* No need to load DLL.  */

#  define GetTickCount64Func GetTickCount64

# endif
-----------------------------------------------

In the 'else' case the warning is triggered since it is just the
function symbol not a pointer to it.

I'm not sure if this idiom came before that warning existed or something
else. In any case if the compiler is smart enough to warn about it then
it is probably smart enough to optimize the check out.

Collin

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Angelo Graziosi]

> after a long time, I built Emacs (baf9f1210a) from master on my Win10
> box and it occurred to me that I get more warnings than I used to.  This
> is with

My MSYS2/UCRT64 build of master (20240724_192011) dose not show warnings:

$ grep -i warn emacs-master-u64-x86_64-20240724_192011-release-build.log
ac-wrapper: autoreconf: warning: auto-detected versions not found ( ); 
falling back to latest available
checking whether C compiler handles -Werror -Wunknown-warning-option... no
checking for C compiler option to allow warnings... -Wno-error
   ELC      emacs-lisp/warnings.elc
   ELC      progmodes/cwarn.elc
org.texi:16157: warning: @anchor should not appear on @item line
org.texi:16170: warning: @anchor should not appear on @item line
./emacs-lisp/warnings.el
./emacs-lisp/warnings.elc
./progmodes/cwarn.el
./progmodes/cwarn.elc

Emacs is built with

gcc version 14.1.0 (Rev3, Built by MSYS2 project)


and configured something like this

--------------------------------------
./configure --prefix="/${PREFIXNAME}" \
                 --host=x86_64-w64-mingw32 \
                 --build=x86_64-w64-mingw32 \
                 --without-dbus \
                 --without-pop \
                 --with-modules \
                 --without-native-compilation \
                 --enable-checking=no \
                 CFLAGS=-O2 -static
--------------------------------------

with the result:

--------------------------------------
Configured for 'x86_64-w64-mingw32'.

   Where should the build process find the source code?    .
   What compiler should emacs be built with? 
x86_64-w64-mingw32-gcc  -O2 -static
   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 -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?                   no
   Does Emacs use version 2 of the X Input Extension?      no
   Does Emacs generate a smaller-size Japanese dictionary? no
--------------------------------------

Also the build of IGC branch produces the same results: no warnings.


Ciao,
  Angelo.

Re: Support for MS-Windows build of Emacs

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> Sadly, the MS-Windows port of Emacs is basically not taken care of
> anymore.

Sad news, indeed.

> There are no active developers on board who seem to care about it,
> except yours truly.

Your work in that area was and is highly appreciated, of course.

> I see this in the (lack of) responses to Windows-specific bugs and
> issues reported to the bug tracker: no one chimes in, even if I
> deliberately leave a bug report without responses for many days.  As
> my free time is severely limited, I only care about aspects that
> affect me directly (and the 64-bit build and GCC 14 are way outside
> that scope).
>
> If no one comes forward and starts taking care of the MS-Windows
> issues, I'm very close to the decision of declaring the Windows build
> of Emacs "unsupported", meaning anyone who needs it are "on their
> own", from my POV as the (co)maintainer.

My impression is that the statement above also applies to the NS-port.

> This is not an April 1 joke: if there's a significant community
> interested in being able to run and develop Emacs on MS-Windows,
> someone should volunteer to take care of the build on a day to day
> basis, or else the conclusion is that there's no general interest in
> that platform among the Emacs community that is high enough to justify
> the investment.

I think there is a demand for Emacs on non-free systems, notably Windows
and macOS, so dropping the support isn't helpful.  But as you said, it
becomes a dead end if the official maintainers don't have the time
and/or willingness etc. to do the job there and no one else steps
forward.

> You _have_ been warned!

Thanks, I'm mostly on macOS nowadays, but that doesn't really mean
"problem solved".

Best, Arash

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

> If the warnings are for Emacs's own sources, please submit a bug
> report.  Gnulib-related warnings should be reported to the Gnulib
> mailing list.

Thanks, will do so.

Best, Arash

Re: Support for MS-Windows build of Emacs

[Po Lu]

Arash Esbati <arash@gnu.org> writes:

> My impression is that the statement above also applies to the NS-port.

That is correct, and is reflected in the condition of the NS port.

>> This is not an April 1 joke: if there's a significant community
>> interested in being able to run and develop Emacs on MS-Windows,
>> someone should volunteer to take care of the build on a day to day
>> basis, or else the conclusion is that there's no general interest in
>> that platform among the Emacs community that is high enough to justify
>> the investment.
>
> I think there is a demand for Emacs on non-free systems, notably Windows
> and macOS, so dropping the support isn't helpful.  But as you said, it
> becomes a dead end if the official maintainers don't have the time
> and/or willingness etc. to do the job there and no one else steps
> forward.

So let's hope that interested parties, having received this fair
warning, make their presence known.

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Pip Cet]

On Thursday, July 25th, 2024 at 08:25, Angelo Graziosi <angelo.g0@libero.it> wrote:
> > after a long time, I built Emacs (baf9f1210a) from master on my Win10
> 
> > box and it occurred to me that I get more warnings than I used to. This
> > is with
> 
> 
> My MSYS2/UCRT64 build of master (20240724_192011) dose not show warnings:

I'm definitely seeing those warnings on what looks like a very similar system, but under wine.

> $ grep -i warn emacs-master-u64-x86_64-20240724_192011-release-build.log

How are you capturing that? (Are you sure you're capturing stderr?)

> ac-wrapper: autoreconf: warning: auto-detected versions not found ( );
> falling back to latest available
> checking whether C compiler handles -Werror -Wunknown-warning-option... no
> checking for C compiler option to allow warnings... -Wno-error
> ELC emacs-lisp/warnings.elc
> ELC progmodes/cwarn.elc
> org.texi:16157: warning: @anchor should not appear on @item line
> org.texi:16170: warning: @anchor should not appear on @item line
> ./emacs-lisp/warnings.el
> ./emacs-lisp/warnings.elc
> ./progmodes/cwarn.el
> ./progmodes/cwarn.elc
> 
> Emacs is built with
> 
> gcc version 14.1.0 (Rev3, Built by MSYS2 project)

Same here.

> Also the build of IGC branch produces the same results: no warnings.

Does it work?

Pip

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Angelo Graziosi]

Il 25/07/2024 18:42, Pip Cet ha scritto:

> 
>> Also the build of IGC branch produces the same results: no warnings.
> 
> Does it work?

I did not know that the build needed '--with-mps' and MPS library which 
does not exist in MSYS2 so the build was really without MPS.

Ciao,
   Angelo.

Re: Warnings during building the current master on Win10 with MSYS2/MinGW64

[Angelo Graziosi]

Il 25/07/2024 18:42, Pip Cet ha scritto:
> 
>> $ grep -i warn emacs-master-u64-x86_64-20240724_192011-release-build.log
> 
> How are you capturing that? (Are you sure you're capturing stderr?)

The log file is created with

build 2>&1 | tee "${log_file}"

in a bash script...

Re: Support for MS-Windows build of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think there is a demand for Emacs on non-free systems, notably Windows
  > and macOS, so dropping the support isn't helpful.  But as you said, it
  > becomes a dead end if the official maintainers don't have the time
  > and/or willingness etc. to do the job there and no one else steps
  > forward.

Our primary goal is developing the GNU operating system.  Other
systems are inherently less important than that, and nonfree systems
even less so.  Given our limited resources, we have to do things this
way.

However, as long as people keep wanting to use Emacs on those nonfree
systems, I hope some of them will step forward and support Emacs there.

Is there a way we can encourage them to?  A good place to post?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

[Tom Davey]

Eli Zaretskii writes: 

> This is not an April 1 joke: if there's a significant community interested in being able 
> to run and develop Emacs on MS-Windows, someone should volunteer to take care 
> of the build on a day to day basis, or else the conclusion is that there's no general 
> interest in that platform among the Emacs community that is high enough to justify 
> the investment.

More than one billion end-user computer systems run some version of Microsoft Windows. Emacs users on Windows usually have no say in their choice of an OS; the rules are set by their employers. 

Appendix H of the Emacs Info Manual expresses this sentiment -- "We support GNU Emacs on proprietary operating systems because we hope this taste of freedom will inspire users to escape from them." -- but this is not how corporate IT departments see the situation. Considerations of security, centralized management, and end-user support make Windows a hard requirement for tens of millions of desktops that could benefit from Emacs. 

Abandoning the behemoth that is Windows strikes me as self-defeating for Emacs. Nobody will get a "taste of freedom" if Emacs fails to provide it to Windows users in the first place.

I do not work as a computer programmer; my technical skills are infinitesimal compared to the people on this list. Emacs, for me, is a very powerful business tool for managing projects and tasks (via Org-mode) and an equally powerful tool for writing prose. I see it becoming my preferred client for generative AI as well. 

I support the Org-mode developers via an annual donation to Librepay. I would happily do the same to keep the Windows builds of Emacs on par with other OSes.

On my two computers, desktop and laptop, evaluating emacs-version() currently returns "GNU Emacs 29.3 (build 2, x86_64-w64-mingw32) of 2024-03-24". My heartfelt thanks to those who made and continue to make this possible. 

Eli, thank you for issuing the warning.

--
Tom Davey
tom@tomdavey.com
New York NY USA

-----Original Message-----
From: emacs-devel-bounces+tom=tomdavey.com@gnu.org <emacs-devel-bounces+tom=tomdavey.com@gnu.org> On Behalf Of Eli Zaretskii
Sent: Thursday, July 25, 2024 1:53 AM
To: emacs-devel@gnu.org
Cc: Arash Esbati <arash@gnu.org>
Subject: Re: Support for MS-Windows build of Emacs (was: Warnings during building the current master on Win10 with MSYS2/MinGW64)

> From: Arash Esbati <arash@gnu.org>
> Date: Wed, 24 Jul 2024 22:16:12 +0200
> 
> after a long time, I built Emacs (baf9f1210a) from master on my Win10 
> box and it occurred to me that I get more warnings than I used to.  
> This is with
> 
> $ gcc --version
> gcc.exe (Rev3, Built by MSYS2 project) 14.1.0

Sadly, the MS-Windows port of Emacs is basically not taken care of anymore.  There are no active developers on board who seem to care about it, except yours truly.  I see this in the (lack of) responses to Windows-specific bugs and issues reported to the bug tracker: no one chimes in, even if I deliberately leave a bug report without responses for many days.  As my free time is severely limited, I only care about aspects that affect me directly (and the 64-bit build and GCC 14 are way outside that scope).

If no one comes forward and starts taking care of the MS-Windows issues, I'm very close to the decision of declaring the Windows build of Emacs "unsupported", meaning anyone who needs it are "on their own", from my POV as the (co)maintainer.

This is not an April 1 joke: if there's a significant community interested in being able to run and develop Emacs on MS-Windows, someone should volunteer to take care of the build on a day to day basis, or else the conclusion is that there's no general interest in that platform among the Emacs community that is high enough to justify the investment.

You _have_ been warned!

Re: Support for MS-Windows build of Emacs

[Arash Esbati]

Richard Stallman <rms@gnu.org> writes:

> Our primary goal is developing the GNU operating system.  Other
> systems are inherently less important than that, and nonfree systems
> even less so.  Given our limited resources, we have to do things this
> way.

I think this part should be crystal clear to everybody who enters the
scene here.

> However, as long as people keep wanting to use Emacs on those nonfree
> systems, I hope some of them will step forward and support Emacs there.
>
> Is there a way we can encourage them to?

I suggest to look back and ask what was the process until now that the
project is facing this situation.  It is hard to give a good answer
without knowing the past; and I'm not long enough around to have a good
judgement.  As a personal note, comments like[1]:

  It is useful for those interested in running Emacs on Losedows to test
  the MPS code on that system, but I request that we all join in
  refusing to refer to Microsoft Losedows as a "win".

don't sound encouraging for people the project is trying to recruit, at
least in my book.

> A good place to post?

I think emacs-devel is the right place.  Eli's last post is already
being noted; see the second link on this page[2].  So I suggest to post
a request for support here, the task and qualification needed, and let
others spread the word.  Let's see what happens then and take it from
there.

Best, Arash

Footnotes:
[1]  https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01204.html
[2]  https://sachachua.com/blog/2024/07/2024-07-29-emacs-news/

Re: Support for MS-Windows build of Emacs

[Eli Zaretskii]

> From: Arash Esbati <arash@gnu.org>
> Cc: eliz@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 30 Jul 2024 16:30:28 +0200
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > However, as long as people keep wanting to use Emacs on those nonfree
> > systems, I hope some of them will step forward and support Emacs there.
> >
> > Is there a way we can encourage them to?
> 
> I suggest to look back and ask what was the process until now that the
> project is facing this situation.

IMO, there's nothing to look at.  We used to have people here who were
both Emacs developers and used Emacs on Windows enough to care about
the port.  They have simply left, for reasons that AFAIR have nothing
to do with us or the way we do things here.

Re: Support for MS-Windows build of Emacs

[Juergen Fenn]

Am 30.07.24 um 18:03 Uhr schrieb Eli Zaretskii:
>>> However, as long as people keep wanting to use Emacs on those nonfree
>>> systems, I hope some of them will step forward and support Emacs there.
>>>
>>> Is there a way we can encourage them to?
>> I suggest to look back and ask what was the process until now that the
>> project is facing this situation.
> IMO, there's nothing to look at.  We used to have people here who were
> both Emacs developers and used Emacs on Windows enough to care about
> the port.  They have simply left, for reasons that AFAIR have nothing
> to do with us or the way we do things here.

I presume it's probably due to a change in the focus of interest from
one generation of developers to the next. What's more, there have been
many changes between macOS versions recently. It is a nuisance indeed to
deal with those because you keep constantly adapting to the next version
of macOS which keeps you from working on new features. I have been
watching this in the TeX Live project and the problems they had to deal
with for MacTeX. It could also be that free software is no longer as
attractive as it used to be when you mention it in the skills section of
your CV.

I suggest we spread the word as far as possible. Post it wherever you
can, blog about it, tell it on the social networks and listen to the
feedback. We could also host a session at EmacsConf.

I'm afraid there is little more that I could do because I feel a lot
like Tom in this thread. I'm not a developer, but I have been using
Emacs for over twenty years, first on Windows, and then and macOS, and I
cannot think of a different editor to use instead. I started using Emacs
when I wrote my dissertation thesis in NTEmacs with AUCTeX. So, your
statement that the non-free ports are mostly unmaintained indeed makes
me feel scared.

Best Regards,
Jürgen.