Re: Adapting changes for MSYS2?

[Bruno Haible]

Following up to 

> I wrote:
> > MSYS, last released in 2016 [0], was a project with big hacks. For example,
> > in the 'exec' system call, it replaces an argv[i] = "/dev/null" with "nul" -
> 
> MSYS2 does similar things, albeit in a more user-controllable way [1].
> 
> Bruno
> 
> [1] 
> https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces

And it still leads to bugs during exec, such as when running libtool:

"libtool hangs indefinitely on windows when used in msys due to cmd.exe call 
bug"
https://savannah.gnu.org/support/?110901

This confirms, once again, that MSYS2 cannot be recommended.

As a development environment for native Windows program, I continue to recommend
Cygwin.

Bruno

Re: Adapting changes for MSYS2?

[arnold]

Bruno Haible  wrote:

> What I could see
>   - from https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin
>   - from analysis of a couple of gnulib test failures
> is that MSYS2, compared to Cygwin, has problems in the area of file 
> permissions,
> symbolic links, and signals (at least).
>
> Since anyone can compile for mingw32, mingw64, MSVC 32-bit, and MSVC 64-bit
> using Cygwin [1], I don't see the point of investing effort into making GNU
> packages build fine on MSYS2.

OTOH, if it's not a lot of work to upstream a few patches, why not?
The more environments that I can easily support out of the box, the
better for my users.

My two cents,

Arnold

Re: Adapting changes for MSYS2?

[Bruno Haible]

What I could see
  - from https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin
  - from analysis of a couple of gnulib test failures
is that MSYS2, compared to Cygwin, has problems in the area of file permissions,
symbolic links, and signals (at least).

Since anyone can compile for mingw32, mingw64, MSVC 32-bit, and MSVC 64-bit
using Cygwin [1], I don't see the point of investing effort into making GNU
packages build fine on MSYS2.

Bruno

[1] see the INSTALL.windows file of GNU gettext

Re: Adapting changes for MSYS2?

[Bruno Haible]

I wrote:
> MSYS, last released in 2016 [0], was a project with big hacks. For example,
> in the 'exec' system call, it replaces an argv[i] = "/dev/null" with "nul" -

MSYS2 does similar things, albeit in a more user-controllable way [1].

Bruno

[1] 
https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces

Re: Adapting changes for MSYS2?

[Bruno Haible]

Hi Paul,

> > * The patch to 'ar-lib' and 'compile' are NOT needed for supporting msys2
> >with the GCC compiler. Their ONLY effect is to support compiling with the
> >MSVC compiler in an msys2 development environment.
> 
> They're still a win for that environment though, no? So I suppose we should 
> leave them in Automake (and Gnulib).

Yes.

Bruno

Re: Adapting changes for MSYS2?

[Paul Eggert]

On 11/11/19 12:51 PM, Bruno Haible wrote:


But 'ar-lib' and 'compile' originate in the Automake repository and are only
mirrored in Gnulib. (See config/srclist.txt.)


Yes, I noticed that after patching those two. I propagated the patch into 
Automake to fix that.



'config.rpath' is derived from libtool.m4. It does not make sense to
add stuff to config.rpath before adding it to libtool.m4.


In that case let's revert the change to config.rpath, as you suggested, until 
the patch is done properly.



MSYS2 is a new project, that is "based on modern Cygwin" [1] / "builds on the
Cygwin project" [2]. The first impressions I got are:
...
   * There is a GPL violation: The homepage https://github.com/msys2/msys2
 has, for the runtime, a link to https://github.com/alexpux/cygwin
 but this is wrong! The real sources of the runtime are likely under
 https://github.com/Alexpux/Cygwin/tree/msys2-master !


This should get fixed, obviously. I don't know who's in charge of MSYS2 to fix 
it.


* The patch to config.guess is not needed.


Yes. I didn't install that one.


* The patch to 'ar-lib' and 'compile' are NOT needed for supporting msys2
   with the GCC compiler. Their ONLY effect is to support compiling with the
   MSVC compiler in an msys2 development environment.


They're still a win for that environment though, no? So I suppose we should 
leave them in Automake (and Gnulib).

Re: Adapting changes for MSYS2?

[Bruno Haible]

Hi Paul,

> I installed most of those changes to Gnulib.

But 'ar-lib' and 'compile' originate in the Automake repository and are only
mirrored in Gnulib. (See config/srclist.txt.)

Similarly, 'config.rpath' is derived from libtool.m4. It does not make sense to
add stuff to config.rpath before adding it to libtool.m4.

More to the background of this patch. You have to distinguish MSYS and MSYS2.

MSYS, last released in 2016 [0], was a project with big hacks. For example,
in the 'exec' system call, it replaces an argv[i] = "/dev/null" with "nul" -
on the mere assumption that this argument must designate a file name that the
callee will attempt to open.

MSYS2 is a new project, that is "based on modern Cygwin" [1] / "builds on the
Cygwin project" [2]. The first impressions I got are:

  * MSYS2 is as solid and as slow as Cygwin.

  * Unlike Cygwin, it does not support symlinks.

  * The text encoding on I/O is UTF-8, like in Cygwin. (It uses mintty.exe,
a full-fledged UTF-8 terminal, like Cygwin.)

  * The predefined symbols in GCC are both __CYGWIN__ and __MSYS__ !

  * There is a GPL violation: The homepage https://github.com/msys2/msys2
has, for the runtime, a link to https://github.com/alexpux/cygwin
but this is wrong! The real sources of the runtime are likely under
https://github.com/Alexpux/Cygwin/tree/msys2-master !
(The difference between the two can be seen here: The uname() system
call returns an OS name of the form "MSYS_NT-10.0-..."; when you look in the
source file winsup/cygwin/uname.cc, function uname_x, you see that it cannot
come from the 'master' branch. It most likely comes from the 'msys2-master'
master.)

  * The build and host system type are x86_64-pc-msys (set by /etc/config.site,
based on environment variables $MSYSTEM, $MSYSTEM_CARCH, $MSYSTEM_CHOST).

  * The Porting documentation [3], section "Platform checks", is wrong: it 
states
that the value of $host_os in configure scripts will be 'mingw32' or 
'msys2',
but in fact it is 'msys'.

  * When I build a gnulib testdir, there are 31 test failures:
FAIL: test-access
FAIL: test-atexit.sh
FAIL: test-chown
FAIL: test-fclose
FAIL: test-fsync
FAIL: test-getcwd.sh
FAIL: test-ilogbl
FAIL: test-lchown
FAIL: test-linkat
FAIL: test-perror.sh
FAIL: test-poll
FAIL: test-pread.sh
FAIL: test-ptsname
FAIL: test-ptsname_r
FAIL: test-pwrite.sh
FAIL: test-raise
FAIL: test-readlinkat
FAIL: test-rename
FAIL: test-renameat
FAIL: test-renameatu
FAIL: test-stat-time
FAIL: test-strfmon_l
FAIL: test-strtold
FAIL: test-init.sh
FAIL: test-unlink
FAIL: test-unlinkat
FAIL: test-utime
FAIL: test-utimens
FAIL: test-utimensat
FAIL: test-verify.sh
FAIL: test-xalloc-die.sh

  * When I build a couple of packages, I see that libtool.m4 (from upstream) 
does
not support shared libraries.

The patch that Arnold forwarded comes from the MSYS2 packages repository.
It shows that it is generally not a good idea to apply patches of which
you don't know what they do and whether they are outdated or current.

* The patch to config.guess is not needed. Without it, the guess platform
  identifier is
x86_64-pc-msys
  With it, it is
x86_64-unknown-msys
  The VENDOR field being irrelevant, the patch is pointless.

* The patch to 'ar-lib' and 'compile' are NOT needed for supporting msys2
  with the GCC compiler. Their ONLY effect is to support compiling with the
  MSVC compiler in an msys2 development environment.
  As already said above, these patches will disappear from gnulib at the
  next sync from Automake, unless added into Automake.

* The patch to config.rpath is premature. When msys2 support is added to
  libtool.m4, config.rpath should follow that. I vote for reverting it
  for now.

Bruno

[0] https://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/
[1] https://www.msys2.org/
[2] https://github.com/msys2/msys2/wiki/MSYS2-introduction
[3] https://github.com/msys2/msys2/wiki/Porting

Re: Adapting changes for MSYS2?

[arnold]

Hi Paul.

Much thanks! I have pulled in the changes to gawk and pushed to git.
I await news from the original reporter (Hi Peter!) as to whether that
does the trick on msys.

W.R.T. your question about config.guess, perhaps Alexey can answer.

Thanks!

Arnold

Paul Eggert  wrote:

> On 11/9/19 10:40 AM, arn...@skeeve.com wrote:
>
> > A gawk user recently called my attention to:
> > 
> > https://github.com/msys2/MSYS2-packages/tree/master/gawk
> > 
> >> The patch file there is named gawk-4.2.1-msysize.patch.  The patches mainly
> >> seem to add an "msys*" option in several build scripts just after the
> >> "cygwin*" system identity alternatives.
> > 
> > I have adapted the patches for gawk's test/Makefile.am and will be
> > pushing shortly.
> > 
> > Can we get the changes for compile, config.guess, config.rpath, and
> > ar-lib integrated directly into GNULIB, so that I can then pull them
> > from upstream?
>
> I installed most of those changes to Gnulib. The exception is the proposed 
> change to config.guess, which is upstream from Gnulib and is part of GNU 
> config, 
> so I'll CC: this message to config-patc...@gnu.org.
>
> As far as I can see, the proposed config.guess change has no effect, as the 
> existing config.guess treats MSYS the same on all architectures in an earlier 
> branch of that big 'case' statement. config.guess has done so since this 
> commit 
> in 2014, which specifically caused config.guess to treat MSYS the same on all 
> machines, not just i* machines:
>
> https://git.savannah.gnu.org/cgit/config.git/commit/?id=f4ebd3ed097771a729b68e688236aea665e7c1f3
>
> so I'm puzzled as to why the config.guess change would be needed even if it 
> were 
> effective.

Re: Adapting changes for MSYS2?

[Paul Eggert]

On 11/9/19 10:40 AM, arn...@skeeve.com wrote:


A gawk user recently called my attention to:

https://github.com/msys2/MSYS2-packages/tree/master/gawk


The patch file there is named gawk-4.2.1-msysize.patch.  The patches mainly
seem to add an "msys*" option in several build scripts just after the
"cygwin*" system identity alternatives.


I have adapted the patches for gawk's test/Makefile.am and will be
pushing shortly.

Can we get the changes for compile, config.guess, config.rpath, and
ar-lib integrated directly into GNULIB, so that I can then pull them
from upstream?


I installed most of those changes to Gnulib. The exception is the proposed 
change to config.guess, which is upstream from Gnulib and is part of GNU config, 
so I'll CC: this message to config-patc...@gnu.org.


As far as I can see, the proposed config.guess change has no effect, as the 
existing config.guess treats MSYS the same on all architectures in an earlier 
branch of that big 'case' statement. config.guess has done so since this commit 
in 2014, which specifically caused config.guess to treat MSYS the same on all 
machines, not just i* machines:


https://git.savannah.gnu.org/cgit/config.git/commit/?id=f4ebd3ed097771a729b68e688236aea665e7c1f3

so I'm puzzled as to why the config.guess change would be needed even if it were 
effective.

Adapting changes for MSYS2?

[arnold]

Hi.

A gawk user recently called my attention to:

https://github.com/msys2/MSYS2-packages/tree/master/gawk

> The patch file there is named gawk-4.2.1-msysize.patch.  The patches mainly
> seem to add an "msys*" option in several build scripts just after the
> "cygwin*" system identity alternatives.

I have adapted the patches for gawk's test/Makefile.am and will be
pushing shortly.

Can we get the changes for compile, config.guess, config.rpath, and
ar-lib integrated directly into GNULIB, so that I can then pull them
from upstream?

They may be small enough that you don't need paperwork.

I'm cc-ing Alexey Pawlow, the author of the changes.

Thanks!

Arnold