bug#28601: 26.0.50; configure: error: Emacs does not support 'x86_64-pc-msys' systems.

[Vincent Belaïche]

Dear Noam,

Answers embedded below...

Le 16/10/2017 à 16:23, Noam Postavsky a écrit :
> On Mon, Oct 16, 2017 at 4:59 AM, Vincent Belaïche
> <vincent.belaiche@gmail.com> wrote:
>
>> I attached a patch to INSTALL.W64 to collect all the instruction needed
>> in my case to install Emacs.
>
>> +In the sequel we denote by c:\MSYS\INSTALL\DIR\msys64 the
>> +directory where MSYS2 is installed, e.g. C:\msys64 by default.
>
> I think just using the default C:\msys64 might be clearer than using
> this kind of meta-syntax.
>

OK, I will revise that.

>> +
>> +* Configure your MSWindows PATH variable
>> +
>>  Then you'll need to add the following directories to your Windows PATH
>>  environment variable:
>>
>> -  c:\msys64\usr\bin;c:\msys64\mingw64\bin
>> +  c:\MSYS\INSTALL\DIR\msys64\usr\bin;c:\MSYS\INSTALL\DIR\msys64\mingw64\bin
>> +
>> +where c:\MSYS\INSTALL\DIR\msys64 depends on your MSYS2 installation,
>> +and is c:\msys64 by default.
>>
>> -you can do this through Control Panel / System and Security / System /
>> +You can do this through Control Panel / System and Security / System /
>>  Advanced system settings / Environment Variables / Edit path.
>>
>>  Adding these directories to your PATH tells Emacs where to find the DLLs it
>>  needs to run, and some optional commands like grep and find.  These commands
>>  will also be available at the Windows console.
>>
>> +Concerning the find command see also the last step about configuring
>> +your init file to get an MSWindows find port.
>> +
>
> Actually I never changed my Windows PATH. Running Emacs 25 outside of
> the MSYS2 environment complains about not finding libwinpthread-1.dll,
> but Emacs 26 works fine. Perhaps we can just remove this section
> entirely?
>

I does not work for me if I don't change MSWindows PATH. But the text
needs revision anyway because it does not say what has to be
ensured.

What happens for me is that c:\MSYS\INSTALL\DIR\msys64\mingw64\bin has
to be high enough in the path list, otherwise Emacs gets frozen on
start.

I have not fully identified how high it has to be. It seems that if it
is not before c:\Perl64\site\bin then the freeze happens (to be
confirmed by more tests). c:\Perl64\site\bin is some ActiveState native
perl implementation which contains a gcc.exe executable but no DLL's.

>>  ** Download and install the necessary packages
>
>> +       for w in msys/msys2-launcher-git \
>
> Is there some reason you changed to a for loop?
>

Yes, I had some packages already installed, and if I just type

pacman -S msys/msys2-launcher-git \
          msys/m4 \
          msys/autoconf \
          msys/grep \
          msys/findutils \
          mingw64/mingw-w64-x86_64-pkg-config \
          mingw64/mingw-w64-x86_64-make \
          mingw64/mingw-w64-x86_64-toolchain \
          mingw64/mingw-w64-x86_64-xpm-nox \
          mingw64/mingw-w64-x86_64-libtiff \
          mingw64/mingw-w64-x86_64-giflib \
          mingw64/mingw-w64-x86_64-libpng \
          mingw64/mingw-w64-x86_64-libjpeg-turbo \
          mingw64/mingw-w64-x86_64-librsvg \
          mingw64/mingw-w64-x86_64-liblcms2 \
          mingw64/mingw-w64-x86_64-libxml2 \
          mingw64/mingw-w64-x86_64-gnutls \
          mingw64/mingw-w64-x86_64-zlib

and I type ENTER for defaulting to « all » then it seems that pacman
does not really re-install anything. With a look thing are handled one
by one more cleanly, and it is easier for the user to discriminate.

I must admit that I have not really checked that nothing is
re-installed: it is just that after ENTER pacman exits immediatly with
saying that it is reinstalled, but I cannot believe that it was done in
almost no time.

>> +** Check your MSYS2 fstab file
>
> Do you mean that your fstab file was broken somehow? I never even
> looked at mine.

MSYS2 was already installed for me some time ago, because I needed a
more recent GNU-make to generate some LaTeX package distribution (the
MSYS1 GNU-Make is bogous with memort handling). So I had already edited
manually the fstab to mount MiKTeX binary directory to /miktex/bin and
have this /miktex/bin in my PATH as set by my ~/.bashrc.

It seems that having done that prevent MSYS2 pacman to update the fstab
when mingw64 stuff is added --- or maybe pacman never tampers with the
fstab, and the /mingw64 mount point was added later than the time when I
installed MSYS2.

>
>> +Otherwise, you will need to exit the MINGW64 console and edit your
>> +~/.bashrc file, where ~ denote
>> +c:\MSYS\INSTALL\DIR\msys64\home\%USERNAME%, to have the correct PATH
>> +variable from MSYS/MINGW32/MINGW64 consoles:
>> +
>> +In this cas, please make sure that ~/.bashrc contains some statement
>> +like:
>
> Do you mean you needed to modify your ~/.bashrc to get the correct
> PATH under mingw64.exe? It should already be set correctly by
> /etc/profile.
>

Well, I have tampered with the original msys2_shell.cmd (what
pre-existed before the launchers were made available) in order to
activate MSWindows native symlinks when I open an MSYS2 console.

See https://github.com/msys2/msys2/issues/71

This works fine, but for some reason when I do that (which amounts to
launching the MSYS2 console through the COM "Shell.Application" with the
"runas" method) then the MSYS2 PATH is the same as my MSWindows PATH (so
it does not contain the /usr/bin etc...). So, to work around this, my
~/.bashrc sets the PATH from scratch w/o using the value at bash
start-up.

This means that whether I use mingw64.exe, mingw32.exe or msys2.exe does
not make any difference to me, and only the ~/.bashrc matters.

Reading again my modified msys2_shell.cmd script and the profile script,
I think that this issue arose from MSYS2_PATH_TYPE not being exported to
the process env that contains the lauched console. This is because all
the msys2_shell.cmd is under setlocal regime.

Anyway, as you see it is better if the user check that the PATH is
correctly set in case that, like me the ~/.bashrc makes some tricks.

> Perhaps we can put this under a "Troubleshooting" section at the end.

Yes, I agree that I was a little naughty, and my troubles were partly
caused by too much hacking.

  Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus