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
