Installing the current emacs-28 branch under Windows 10

Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Hello Emacs

I'm trying to compile the latest emacs-28 branch (which is compiling
under GNU-Linux). I adhered exactly to the recipes of
etc/nt/INSTALL.W64. But I'm already at the end of my tether.  What would
you do in below situation?

Thanks for your support

       Dieter
----------------------------------------------------------------------

uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs
$ ./autogen.sh
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' ...
' is already registered with AC_CONFIG_FILES.
../autoconf-2.71/lib/autoconf/status.m4:289: AC_CONFIG_FILES is expanded from...
configure.ac:6010: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
autoreconf: error: /usr/bin/autoconf failed with exit status: 1

----------------------------------------------------------------------

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Date: Tue, 12 Oct 2021 11:23:35 +0200
> Cc: Phillip Lord <phillip.lord@russet.org.uk>
> 
> I'm trying to compile the latest emacs-28 branch (which is compiling
> under GNU-Linux). I adhered exactly to the recipes of
> etc/nt/INSTALL.W64. But I'm already at the end of my tether.  What would
> you do in below situation?
> 
> Thanks for your support
> 
>        Dieter
> ----------------------------------------------------------------------
> 
> uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs
> $ ./autogen.sh
> 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' ...
> ' is already registered with AC_CONFIG_FILES.
> ../autoconf-2.71/lib/autoconf/status.m4:289: AC_CONFIG_FILES is expanded from...
> configure.ac:6010: the top level
> autom4te: error: /usr/bin/m4 failed with exit status: 1
> autoreconf: error: /usr/bin/autoconf failed with exit status: 1

No idea.  Sounds like some end-of-line issue?  How did you configure
Git wrt EOLs?

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> autom4te: error: /usr/bin/m4 failed with exit status: 1
>> autoreconf: error: /usr/bin/autoconf failed with exit status: 1
>
> No idea.  Sounds like some end-of-line issue?  How did you configure
> Git wrt EOLs?

It is

uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs (emacs-28)
$ git config --list |grep crlf
core.autocrlf=true

Must be the default for this git installation on Windows, I didn't touch
it.  A sample of text files are encoded in undecided-dos in the emacs
repo.  Do the files need to be encoded in Unix style line endings for
MinGW tools?

Thank you

      Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
> Date: Tue, 12 Oct 2021 20:02:43 +0200
> 
> uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs (emacs-28)
> $ git config --list |grep crlf
> core.autocrlf=true

Bad idea: it should be 'false'.  Git should not change the EOLs,
neither when it checks out files, nor when it pushes them upstream.

I'm not sure this is the root cause of your problem, but it might be.
Suggest to reconfigure Git, and then delete your local repository and
clone it again.

> Must be the default for this git installation on Windows, I didn't touch
> it.

When you install Git, it asks you how you want to treat EOLs, and you
should have selected "checkout as-is, checkin as-is" (or somesuch, I
don't remember the exact wording).

> A sample of text files are encoded in undecided-dos in the emacs
> repo.  Do the files need to be encoded in Unix style line endings for
> MinGW tools?

Not for MinGW, for MSYS.  The autotools you run are MSYS tools, and
MSYS is a fork of Cygwin; Cygwin tools expect Unix-style EOLs, yes.
They could definitely choke if they see Windows-style CRLF EOLs.

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> core.autocrlf=true
>
> Bad idea: it should be 'false'.  Git should not change the EOLs,
> neither when it checks out files, nor when it pushes them upstream.

Excuse me, I overlooked the crlf hint in the (optional) git section of
INSTALL.w64.

> I'm not sure this is the root cause of your problem, but it might be.
> Suggest to reconfigure Git, and then delete your local repository and
> clone it again.

I did that and an emacs-28.0.60 was build :-) thank you very much!

>> Must be the default for this git installation on Windows, I didn't touch
>> it.
>
> When you install Git, it asks you how you want to treat EOLs, and you
> should have selected "checkout as-is, checkin as-is" (or somesuch, I
> don't remember the exact wording).

Well, git slumbered on this Windows system for a few years, I can't
remember...

>> A sample of text files are encoded in undecided-dos in the emacs
>> repo.  Do the files need to be encoded in Unix style line endings for
>> MinGW tools?
>
> Not for MinGW, for MSYS.  The autotools you run are MSYS tools, and
> MSYS is a fork of Cygwin; Cygwin tools expect Unix-style EOLs, yes.

I see, MinGW is a compiler collection and MSYS is the tooling twiddle,
thanks for the explanation.


One observation so far: The Emacs executable can't find its own info
files!  It seems that in the info viewer are only core utils.


     Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Installing the current emacs-28 branch under Windows 10

[Óscar Fuentes]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> One observation so far: The Emacs executable can't find its own info
> files!  It seems that in the info viewer are only core utils.

That's a long-standing problem on MSYS2/Mingw-w64 Emacs. The info files
are installed, but they are not directly accesible through M-x info. You
still can visit an info file and M-x Info-mode.

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: emacs-devel@gnu.org,  phillip.lord@russet.org.uk
> Date: Wed, 13 Oct 2021 22:30:10 +0200
> 
> > I'm not sure this is the root cause of your problem, but it might be.
> > Suggest to reconfigure Git, and then delete your local repository and
> > clone it again.
> 
> I did that and an emacs-28.0.60 was build :-) thank you very much!

Glad my stab in the dark worked.

> >> A sample of text files are encoded in undecided-dos in the emacs
> >> repo.  Do the files need to be encoded in Unix style line endings for
> >> MinGW tools?
> >
> > Not for MinGW, for MSYS.  The autotools you run are MSYS tools, and
> > MSYS is a fork of Cygwin; Cygwin tools expect Unix-style EOLs, yes.
> 
> I see, MinGW is a compiler collection and MSYS is the tooling twiddle,
> thanks for the explanation.

MSYS is needed for everything that expects a Posix shell: the
autogen.sh and configure scripts, the shell commands in Makefiles,
etc.

> One observation so far: The Emacs executable can't find its own info
> files!  It seems that in the info viewer are only core utils.

I have no such problem here.  Does that happen in "emacs -Q"?

Do you have INFOPATH set in the environment?

Also, what is the value of Info-default-directory-list immediately
after entering "emacs -Q", and what is the value of
Info-directory-list after invoking "M-x info" in "emacs -Q"?

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 13 Oct 2021 23:28:18 +0200
> 
> "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:
> 
> > One observation so far: The Emacs executable can't find its own info
> > files!  It seems that in the info viewer are only core utils.
> 
> That's a long-standing problem on MSYS2/Mingw-w64 Emacs. The info files
> are installed, but they are not directly accesible through M-x info. You
> still can visit an info file and M-x Info-mode.

I don't have this problem here with a MinGW built Emacs.

How come this is "a long-standing problem" about which we have no bug
report and no solution?  Can you tell the details so we could try
fixing this?

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> One observation so far: The Emacs executable can't find its own info
>> files!  It seems that in the info viewer are only core utils.
>
> I have no such problem here.  Does that happen in "emacs -Q"?

Yes (I needed three shells to get emacs-28.0.60 -Q started)

> Do you have INFOPATH set in the environment?

I didn't set INFOPATH (checked ~/.bashrc, I think it isn't a Windows
environment variable).

> Also, what is the value of Info-default-directory-list immediately
> after entering "emacs -Q", and what is the value of
> Info-directory-list after invoking "M-x info" in "emacs -Q"?

Please have a look below, in summary: The Info variables are looking
very fishy!

------------------------------
1) Windows command prompt, didn't work
------------------------------

In the installation folder:
runemacs.exe -Q

=> libgmp-10.dll not found

By the way, there was no runemacs.bat in the installation directory
created.

------------------------------
2) MSYS2 MSYS, didn't work either
------------------------------

uidg1626@VSL7V7PW MSYS /d/Emacs/emacs28/bin
$ echo $INFOPATH
/usr/local/info:/usr/share/info:/usr/info:/share/info

then

$ ./runemacs.exe -Q

=> No Emacs GUI!  No error message, next try:

uidg1626@VSL7V7PW MSYS /d/Emacs/emacs28/bin
$ ./emacs-28.0.60.exe -Q
D:/Emacs/emacs28/bin/emacs-28.0.60.exe: error while loading shared libraries: libgmp-10.dll: cannot open shared object file: No such file or directory

=> No Emacs GUI.

------------------------------
3) MSYS2 MinGW 64-bit, is working
------------------------------

uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs-28/info
$ echo $INFOPATH
/usr/local/info:/usr/share/info:/usr/info:/share/info

changed to the installation folder: /d/Emacs/emacs28/bin
$ ./runemacs.exe -Q

INFOPATH seen by Emacs (before C-h i):
C-u M-! echo $INFOPATH
D:\appl\MSYS2\usr\local\info;D:\appl\MSYS2\usr\share\info;D:\appl\MSYS2\usr\info;D:\appl\MSYS2\share\info

Info-default-directory-list C-u C-x e ("%emacs_dir%/share/info/")

Then Info: C-h i
=> No emacs menu item in (dir) Top.

Info-directory-list C-u C-x e ("D:\\appl\\MSYS2\\usr\\share\\info")
----------------------------------------------------------------------

Thank you

      Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Date: Thu, 14 Oct 2021 17:59:57 +0200
> 
> > I have no such problem here.  Does that happen in "emacs -Q"?
> 
> Yes (I needed three shells to get emacs-28.0.60 -Q started)

See below for the reasons.

> > Do you have INFOPATH set in the environment?
> 
> I didn't set INFOPATH (checked ~/.bashrc, I think it isn't a Windows
> environment variable).

It isn't.  But when you start Emacs from the MSYS Bash, you get fed
the INFOPATH value that's set there, for whatever reasons.  I don't
know where INFOPATH is defined and why; if that's not what you want,
perhaps edit your MSYS/Bash init files to remove or update the
setting, because it _will_ get in the way.

> ------------------------------
> 1) Windows command prompt, didn't work
> ------------------------------
> 
> In the installation folder:
> runemacs.exe -Q
> 
> => libgmp-10.dll not found

That means libgmp-10.dll is not on PATH.  Why not?  You should have
the directory with MinGW DLLs on your system's PATH.

> By the way, there was no runemacs.bat in the installation directory
> created.

Neither should there be.  Why did you expect to see runemacs.bat?

> ------------------------------
> 2) MSYS2 MSYS, didn't work either
> ------------------------------
> 
> uidg1626@VSL7V7PW MSYS /d/Emacs/emacs28/bin
> $ echo $INFOPATH
> /usr/local/info:/usr/share/info:/usr/info:/share/info
> 
> then
> 
> $ ./runemacs.exe -Q
> 
> => No Emacs GUI!

Strange.  Probably something MSYS does to prevent that.  But you
shouldn't invoke Emacs from MSYS shell.

> No error message, next try:
> 
> uidg1626@VSL7V7PW MSYS /d/Emacs/emacs28/bin
> $ ./emacs-28.0.60.exe -Q
> D:/Emacs/emacs28/bin/emacs-28.0.60.exe: error while loading shared libraries: libgmp-10.dll: cannot open shared object file: No such file or directory

Again, libgmp-10.dll is not on PATH.

> ------------------------------
> 3) MSYS2 MinGW 64-bit, is working
> ------------------------------
> 
> uidg1626@VSL7V7PW MINGW64 /d/Emacs/emacs-28/info
> $ echo $INFOPATH
> /usr/local/info:/usr/share/info:/usr/info:/share/info
> 
> changed to the installation folder: /d/Emacs/emacs28/bin
> $ ./runemacs.exe -Q
> 
> INFOPATH seen by Emacs (before C-h i):
> C-u M-! echo $INFOPATH
> D:\appl\MSYS2\usr\local\info;D:\appl\MSYS2\usr\share\info;D:\appl\MSYS2\usr\info;D:\appl\MSYS2\share\info
> 
> Info-default-directory-list C-u C-x e ("%emacs_dir%/share/info/")
> 
> Then Info: C-h i
> => No emacs menu item in (dir) Top.
> 
> Info-directory-list C-u C-x e ("D:\\appl\\MSYS2\\usr\\share\\info")

And that is your problem: INFOPATH is set, but it points to Posix
directories, and doesn't include the directory where Emacs installs
its Info files.  You should either unset INFOPATH or update it to
include the directory where Emacs installs its Info files.  If you
want to run Emacs from its source tree, it is best to remove INFOPATH
from the environment.

And make sure the directory with MinGW DLLs is on PATH.

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> I didn't set INFOPATH (checked ~/.bashrc, I think it isn't a Windows
>> environment variable).
>
> It isn't.  But when you start Emacs from the MSYS Bash, you get fed
> the INFOPATH value that's set there, for whatever reasons.  I don't
> know where INFOPATH is defined and why; if that's not what you want,

The culprits are: /etc/bash.bashrc which sources /etc/profile and
herein we have:

INFOPATH='/usr/local/info:/usr/share/info:/usr/info:/share/info'

> perhaps edit your MSYS/Bash init files to remove or update the
> setting, because it _will_ get in the way.

:-)
setting in ~/.bashrc:

INFOPATH="/d/Emacs/emacs28/share/info/":$INFOPATH

(Otherwise I'm loosing the GNU core util infos.)

Info-directory-list became then:
("D:\\Emacs\\emacs28\\share\\info\\" "D:\\appl\\MSYS2\\usr\\share\\info")

Works for me, at least when starting under the MinGW shell, thank you
very much!  But why is Emacs switching here to the Windows path
notation, I thought Emacs is using internally always slashes?

Then, I've to check if this works when starting Emacs without a shell.
Presumably not, maybe I've to set then the environment variable in the
OS?

>> By the way, there was no runemacs.bat in the installation directory
>> created.
>
> Neither should there be.  Why did you expect to see runemacs.bat?

I think runemacs.bat is coming from the Emacs installers for Windows.
Its sole content is:

runemacs.exe -Q

Helpful, didn't know that, but I'd rename it to emacs-Q.bat...

>> ------------------------------
>> 3) MSYS2 MinGW 64-bit, is working
>> ------------------------------

> And make sure the directory with MinGW DLLs is on PATH.

Thanks, will do :-)

I'd also like to mention, that the MSYS2 shells - seemingly - have no
job control: C-z in the terminal window means Emacs is gone forever :-/
Thankfully C-z under Gnu-Emacs just minimises it.


Well, the next topics will be the "little helper" programs ;-)

M-$
apply: Searching for program: No such file or directory, ispell

and gpg when doing (list-packages)

Failed to verify signature archive-contents.sig:
No public key for 066DAFCB81E42C40 created at 2021-10-13T23:10:03+0200 using RSA
Command output:
gpg: keyblock resource '/c/Users/uidg1626/.emacs.d/log/c:/Users/uidg1626/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory
gpg: Signature made Wed Oct 13 23:10:03 2021 WEST
gpg:                using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40
gpg: Can't check signature: No public key

     Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Date: Fri, 15 Oct 2021 11:26:22 +0200
> 
> setting in ~/.bashrc:
> 
> INFOPATH="/d/Emacs/emacs28/share/info/":$INFOPATH
> 
> (Otherwise I'm loosing the GNU core util infos.)
> 
> Info-directory-list became then:
> ("D:\\Emacs\\emacs28\\share\\info\\" "D:\\appl\\MSYS2\\usr\\share\\info")
> 
> Works for me, at least when starting under the MinGW shell, thank you
> very much!  But why is Emacs switching here to the Windows path
> notation, I thought Emacs is using internally always slashes?

It's not Emacs that does that, it's MSYS.  One of the "special things"
it does, and the reason why it's a fork of Cygwin, is that it converts
Posix-style /foo/bar file names to Windows-style X:\SOMETHING\foo\bar,
where "X:\SOMETHING" comes from MSYS notion of where the root of the
Posix tree lives, unless the original file name starts with something
like "/d/", in which case it's converted to "D:\".  Emacs can deal
with both forward and backslashes alike.

> Then, I've to check if this works when starting Emacs without a shell.
> Presumably not, maybe I've to set then the environment variable in the
> OS?

Yes, if you install the Info files unrelated to Emacs in a place that
doesn't match the value of Info-default-directory-list.

> >> By the way, there was no runemacs.bat in the installation directory
> >> created.
> >
> > Neither should there be.  Why did you expect to see runemacs.bat?
> 
> I think runemacs.bat is coming from the Emacs installers for Windows.
> Its sole content is:
> 
> runemacs.exe -Q
> 
> Helpful, didn't know that, but I'd rename it to emacs-Q.bat...

I think this batch file shouldn't be there, as it just muddies the
waters.  But it isn't our call to make, it's the call of those who
produced the batch file and added it to the distribution.

> Well, the next topics will be the "little helper" programs ;-)
> 
> M-$
> apply: Searching for program: No such file or directory, ispell
> 
> and gpg when doing (list-packages)

You need to install those programs, and make sure they are MinGW
programs, not MSYS programs.  The latter might work, but could have
subtle "issues", because they are not really native Windows programs,
whereas the Emacs you built is.

> Command output:
> gpg: keyblock resource '/c/Users/uidg1626/.emacs.d/log/c:/Users/uidg1626/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory

That it reports an MSYS-style file name means you are invoking Emacs
from MSYS shell.  Don't.

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>

>> Then, I've to check if this works when starting Emacs without a shell.
>> Presumably not, maybe I've to set then the environment variable in the
>> OS?
>
> Yes, if you install the Info files unrelated to Emacs in a place that
> doesn't match the value of Info-default-directory-list.

I see ... And then it is even more convenient doing

(add-to-list 'Info-directory-list "d:/appl/MSYS2/usr/share/info" 'append)

than creating an INFOPATH variable.

Thanks

>> >> By the way, there was no runemacs.bat in the installation directory
>> >> created.
>> >
>> > Neither should there be.  Why did you expect to see runemacs.bat?
>> 
>> I think runemacs.bat is coming from the Emacs installers for Windows.
>> Its sole content is:
>> 
>> runemacs.exe -Q
>> 
>> Helpful, didn't know that, but I'd rename it to emacs-Q.bat...
>
> I think this batch file shouldn't be there, as it just muddies the
> waters.  But it isn't our call to make, it's the call of those who
> produced the batch file and added it to the distribution.

I see, probably caught some other Emacs distribution than GNU's.
E.g. runemacs.bat isn't there when installing emacs-27.2 from
http://ftp.gnu.org/gnu/emacs/windows/.

>> Well, the next topics will be the "little helper" programs ;-)
>> 
>> M-$
>> apply: Searching for program: No such file or directory, ispell
>> 
>> and gpg when doing (list-packages)
>
> You need to install those programs, and make sure they are MinGW
> programs, not MSYS programs.  The latter might work, but could have
> subtle "issues", because they are not really native Windows programs,
> whereas the Emacs you built is.

Thanks for the hint...  I think at this stage I'll consult Phillip Lord,
which programs he recommends and how to build them..

>> Command output:
>> gpg: keyblock resource
>> '/c/Users/uidg1626/.emacs.d/log/c:/Users/uidg1626/.emacs.d/elpa/gnupg/pubring.kbx':
>> No such file or directory
>
> That it reports an MSYS-style file name means you are invoking Emacs
> from MSYS shell.  Don't.

Won't ;-)

Thank you very much

  Dieter

Re: Installing the current emacs-28 branch under Windows 10

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> That's a long-standing problem on MSYS2/Mingw-w64 Emacs. The info files
>> are installed, but they are not directly accesible through M-x info. You
>> still can visit an info file and M-x Info-mode.
>
> I don't have this problem here with a MinGW built Emacs.
>
> How come this is "a long-standing problem" about which we have no bug
> report and no solution?  Can you tell the details so we could try
> fixing this?

I'm pretty sure it is a problem on our side.

https://github.com/msys2/MINGW-packages/issues/631

Re: Installing the current emacs-28 branch under Windows 10

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm pretty sure it is a problem on our side.

"our side" == MSYS2

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:

>> You need to install those programs, and make sure they are MinGW
>> programs, not MSYS programs.  The latter might work, but could have
>> subtle "issues", because they are not really native Windows programs,
>> whereas the Emacs you built is.
>
> Thanks for the hint...  I think at this stage I'll consult Phillip Lord,
> which programs he recommends and how to build them..

I was mistaken, in the distributions from Phil Lord are no GNU
"utilities" compiled.  So I installed hunspell from the EZWinPorts
(didn't find ispell and aspell there).  Hunspell is working nicely and
is starting much faster than the ispell/aspell program I had before,
thank you for the ports!  (Further dictionaries can be found here
https://github.com/LibreOffice/dictionaries.)

I also tried to compile hunspell myself and was astonished that
./configure didn't work under the MinGW32 shell only under MinGW64!
Only then I had a closer look and realised that my Emacs compilation
says "x86_64-w64-mingw32".  I'm thoroughly confused, it was compiled
under the MinGW64 shell and now it says -mingw32?  Is the Emacs
executable a 64 bit program or 32 bit which is running on a x86_64
architecture?

Re: Installing the current emacs-28 branch under Windows 10

[Óscar Fuentes]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> I also tried to compile hunspell myself and was astonished that
> ./configure didn't work under the MinGW32 shell only under MinGW64!
> Only then I had a closer look and realised that my Emacs compilation
> says "x86_64-w64-mingw32".  I'm thoroughly confused, it was compiled
> under the MinGW64 shell and now it says -mingw32?  Is the Emacs
> executable a 64 bit program or 32 bit which is running on a x86_64
> architecture?

It is normal you are confused, the naming around MinGW is a mess, and
even worse if you add MSYS2.

In this case mingw32 simply means MinGW, which comes from the "old"
MinGW32 project (as it was originally named) and applies too to the
"new" MinGW-w64, w64 means the MinGW-w64 runtime and x86_64 is the
hardware architecture.

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Óscar Fuentes <ofv@wanadoo.es> writes:

> "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:
>
>> I also tried to compile hunspell myself and was astonished that
>> ./configure didn't work under the MinGW32 shell only under MinGW64!
>> Only then I had a closer look and realised that my Emacs compilation
>> says "x86_64-w64-mingw32".  I'm thoroughly confused, it was compiled
>> under the MinGW64 shell and now it says -mingw32?  Is the Emacs
>> executable a 64 bit program or 32 bit which is running on a x86_64
>> architecture?
>
> It is normal you are confused, the naming around MinGW is a mess, and
> even worse if you add MSYS2.
>
> In this case mingw32 simply means MinGW, which comes from the "old"
> MinGW32 project (as it was originally named) and applies too to the
> "new" MinGW-w64, w64 means the MinGW-w64 runtime and x86_64 is the
> hardware architecture.

Got it, thanks a lot. :-)

(The next adventure'll be to compile pdf-tools with MinGW. It's coming
with a recipe for Windows, hope I don't have to ask for help)

    

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> "utilities" compiled.  So I installed hunspell from the EZWinPorts
> (didn't find ispell and aspell there).  Hunspell is working nicely and
> is starting much faster than the ispell/aspell program I had before,
> thank you for the ports!  (Further dictionaries can be found here
> https://github.com/LibreOffice/dictionaries.)

In the meantime I added some additional ports to the same ezwinports
tree.  (The archives for which, gnutls, binutils and findutils and I
always chose: Overwrite existing files.)  After this M-$ bailed out with
the message:

ispell-check-version: d:/appl/ezwinports/bin/hunspell.exe exited with
code 53

Only after unarchiving the hunspell port in this tree it could be used
again.  Is there a better strategy to use a multiude of ezwinports?

Re: Installing the current emacs-28 branch under Windows 10

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Date: Tue, 19 Oct 2021 21:43:23 +0200
> 
> In the meantime I added some additional ports to the same ezwinports
> tree.  (The archives for which, gnutls, binutils and findutils and I
> always chose: Overwrite existing files.)  After this M-$ bailed out with
> the message:
> 
> ispell-check-version: d:/appl/ezwinports/bin/hunspell.exe exited with
> code 53

Are all of the archives from ezwinports?  If so, you should overwrite
files only if the files you overwrite them by are newer.  That is,
never overwrite newer files by older files.

If you mix with binaries from other places, I don't know what to
suggest, but at least make sure not to mix 32-bit binaries with 64-bit
ones.

> Only after unarchiving the hunspell port in this tree it could be used
> again.

What is "this tree"?

Re: Installing the current emacs-28 branch under Windows 10

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>

>> ispell-check-version: d:/appl/ezwinports/bin/hunspell.exe exited with
>> code 53
>
> Are all of the archives from ezwinports? 

Yes

>  If so, you should overwrite files only if the files you overwrite
> them by are newer.  That is, never overwrite newer files by older
> files.

I'll take care the next time, thank you!

> If you mix with binaries from other places, I don't know what to
> suggest, but at least make sure not to mix 32-bit binaries with 64-bit
> ones.

I don't have the intention to use more sources.  :-) It's already a mess
of various distributions, for TexLive, Git, Putty, EZWinPorts, MSYS2, R,
...

I've seen that the MSYS repos offer also texlive, putty; over 10,000
packages https://packages.msys2.org/package/, it might be more
convenient to assemble the "environment" of Emacs with MSYS and
EZWinPorts alone.

>> Only after unarchiving the hunspell port in this tree it could be used
>> again.
>
> What is "this tree"?

I meant the tree structure of the archives what you describe in the
EZWinPorts' README.txt as "preserving the directory structure recorded
in it".

Bye
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany