Adapting changes for MSYS2?

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

Re: Adapting changes for MSYS2?

[Paul Eggert]

On 11/9/19 10:40 AM, arnold@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-patches@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?

[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 <eggert@cs.ucla.edu> wrote:

> On 11/9/19 10:40 AM, arnold@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-patches@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?

[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?

[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,

> > * 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?

[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]

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?

[arnold]

Bruno Haible <bruno@clisp.org> 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