* Adapting changes for MSYS2?
@ 2019-11-09 18:40 arnold
2019-11-09 20:07 ` Paul Eggert
0 siblings, 1 reply; 9+ messages in thread
From: arnold @ 2019-11-09 18:40 UTC (permalink / raw)
To: bug-gnulib; +Cc: alexey.pawlow
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-09 18:40 Adapting changes for MSYS2? arnold
@ 2019-11-09 20:07 ` Paul Eggert
2019-11-10 19:30 ` arnold
2019-11-11 20:51 ` Bruno Haible
0 siblings, 2 replies; 9+ messages in thread
From: Paul Eggert @ 2019-11-09 20:07 UTC (permalink / raw)
To: arnold, bug-gnulib; +Cc: alexey.pawlow, config-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-09 20:07 ` Paul Eggert
@ 2019-11-10 19:30 ` arnold
2019-11-11 20:51 ` Bruno Haible
1 sibling, 0 replies; 9+ messages in thread
From: arnold @ 2019-11-10 19:30 UTC (permalink / raw)
To: eggert, bug-gnulib, arnold; +Cc: alexey.pawlow, config-patches
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-09 20:07 ` Paul Eggert
2019-11-10 19:30 ` arnold
@ 2019-11-11 20:51 ` Bruno Haible
2019-11-11 21:41 ` Paul Eggert
2019-11-12 1:34 ` Bruno Haible
1 sibling, 2 replies; 9+ messages in thread
From: Bruno Haible @ 2019-11-11 20:51 UTC (permalink / raw)
To: bug-gnulib; +Cc: alexey.pawlow, Paul Eggert, arnold, config-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-11 20:51 ` Bruno Haible
@ 2019-11-11 21:41 ` Paul Eggert
2019-11-11 23:49 ` Bruno Haible
2019-11-12 1:34 ` Bruno Haible
1 sibling, 1 reply; 9+ messages in thread
From: Paul Eggert @ 2019-11-11 21:41 UTC (permalink / raw)
To: Bruno Haible, bug-gnulib; +Cc: alexey.pawlow, arnold, config-patches
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-11 21:41 ` Paul Eggert
@ 2019-11-11 23:49 ` Bruno Haible
0 siblings, 0 replies; 9+ messages in thread
From: Bruno Haible @ 2019-11-11 23:49 UTC (permalink / raw)
To: Paul Eggert; +Cc: alexey.pawlow, arnold, bug-gnulib, config-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-11 20:51 ` Bruno Haible
2019-11-11 21:41 ` Paul Eggert
@ 2019-11-12 1:34 ` Bruno Haible
2019-11-16 12:22 ` Bruno Haible
1 sibling, 1 reply; 9+ messages in thread
From: Bruno Haible @ 2019-11-12 1:34 UTC (permalink / raw)
To: bug-gnulib; +Cc: alexey.pawlow, Paul Eggert, arnold
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-12 1:34 ` Bruno Haible
@ 2019-11-16 12:22 ` Bruno Haible
2019-11-16 18:27 ` arnold
0 siblings, 1 reply; 9+ messages in thread
From: Bruno Haible @ 2019-11-16 12:22 UTC (permalink / raw)
To: bug-gnulib; +Cc: alexey.pawlow, Paul Eggert, arnold
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Adapting changes for MSYS2?
2019-11-16 12:22 ` Bruno Haible
@ 2019-11-16 18:27 ` arnold
0 siblings, 0 replies; 9+ messages in thread
From: arnold @ 2019-11-16 18:27 UTC (permalink / raw)
To: bug-gnulib, bruno; +Cc: alexey.pawlow, eggert, 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-16 18:28 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-09 18:40 Adapting changes for MSYS2? arnold
2019-11-09 20:07 ` Paul Eggert
2019-11-10 19:30 ` arnold
2019-11-11 20:51 ` Bruno Haible
2019-11-11 21:41 ` Paul Eggert
2019-11-11 23:49 ` Bruno Haible
2019-11-12 1:34 ` Bruno Haible
2019-11-16 12:22 ` Bruno Haible
2019-11-16 18:27 ` arnold
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).