[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adapting changes for MSYS2?

From: Bruno Haible
Subject: Re: Adapting changes for MSYS2?
Date: Mon, 11 Nov 2019 21:51:18 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-166-generic; KDE/5.18.0; x86_64; ; )

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
    has, for the runtime, a link to
    but this is wrong! The real sources of the runtime are likely under !
    (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/, function uname_x, you see that it cannot
    come from the 'master' branch. It most likely comes from the 'msys2-master'

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

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

  * When I build a gnulib testdir, there are 31 test failures:
    FAIL: test-access
    FAIL: test-chown
    FAIL: test-fclose
    FAIL: test-fsync
    FAIL: test-ilogbl
    FAIL: test-lchown
    FAIL: test-linkat
    FAIL: test-poll
    FAIL: test-ptsname
    FAIL: test-ptsname_r
    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-unlink
    FAIL: test-unlinkat
    FAIL: test-utime
    FAIL: test-utimens
    FAIL: test-utimensat

  * When I build a couple of packages, I see that libtool.m4 (from upstream) 
    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
  With it, it is
  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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]