[gentoo-alt] Re: Future of x64-cygwin, x86-winnt?

[Michael Haubenwallner]

On 1/18/21 5:42 PM, Sid Spry wrote:
> On Thu, Jan 14, 2021, at 5:38 AM, Fabian Groffen wrote:
>> Please chime in if you have an opinion, info, interest, etc.
>>
>
> Chiming in to state the platforms are all subtly different. Cygwin
> is POSIX compliant (or tries to be) and allows access to the underlying
> Windows APIs while WSL does not generally allow access to the rest
> of the system.

Exactly. However, since some version, WSL seems to be able to execute
binaries from the underlying Windows system, quite similar to Cygwin.

> MSYS2 does not aim for full POSIX compliance but does
> try to offer a familiar build environment. It also supplies a package
> manager CLI.

AFAICT, the MSYS2 distro uses the Cygwin DLL, but configured a little
less POSIXly, so we have decided to stick with the Cygwin distro as the
POSIX system to run Gentoo Prefix on Windows when Interix phased out.
Meanwhile, as WSL becomes more mature, and for Cygwin it is getting
harder to retain a working fork() call, WSL is a real alternative now.

>
> When I help someone support Windows as a target I typically suggest
> using MSYS2. Server or containerized workloads are easily relocated
> to WSL2 but many user facing programs can not be moved to WSL2.
>
> I am not exactly sure this helps.
>
> I was not aware of the winnt target.
> I will see if it is useful for my purposes, as (as usual) I get annoyed
> by package managers not having the latest packages and needing
> to build them myself in MSYS2.
>
> Is it possible to briefly describe the challenges of the targets?

Thanks for this question! Feels like answering is some final task for me.

There is the Parity[1] wrapper around the MSVC toolchain that does allow
to use cl.exe, link.exe and others via GCCish commandline interface. For
example$ i686-msvc16-winnt-gcc -c hello.c -o hello.exe
uses cl.exe and link.exe behind the scenes to create an MSVC native exe.

This allows to use existing POSIX build ecosystems to create native Windows
binaries: Similar to MinGW, but with MSVC toolchain, allowing to call for
M$ support if necessary.

Also, Parity does provide some header files and a static library, to allow
for some POSIX functions to be used without #ifdef _WIN32 in the source
code, reducing the amount of code changes when porting to native MSVC.
An ultimative goal could be to compile LibreOffice with MSVC using Parity
(they do use MinGW right now).

However, unlike MinGW, Parity requires the POSIXish build system to be able
to execute the MSVC toolchain, installed as usual on the Windows host system.
This is true for Interix, Cygwin and MSYS, and WSL1/2 replacing Interix.
Furthermore, Gentoo Portage (the package manager) is written in Python and
Bash, and requires the fork() system call to survive binaries being replaced.

Hence, we use Portage running (in a Gentoo Prefix instance) on the POSIXish
system, to manage a "stacked" instance of Gentoo Prefix, containing the
Windows binaries built via Parity.

Later on, using the POSIXish build system again, the final application is
built via Parity as well, linked against the Windows libraries found in the
"stacked" Prefix instance.

Finally, the POSIXish system is not required to run the application binaries.

As the created Windows binaries can be executed within the build system,
we do not require all the additional effort around real "cross" compiling
as with MinGW on Linux (unless Wine is installed too).
Instead, one could think of additional "multilib" variants here.

For completion, MSVC provides 4 variants of the runtime libs:
 dynamically linked ("msvc"), dynamically linked with debug info ("msvcd"),
 statically linked ("libcmt"), statically linked with debug info ("libcmtd").
Mixing them within a single process is asking for troubles, so Parity does
select the runtime variant along the host triplet. As multiple MSVC versions
can be installed together on the same Windows machine, the MSVC version used
is also selected along the host triplet. For example:
 i686-msvc16-winnt: 32bit, dynamically linked runtime, Visual Studio 2019
 x86_64-msvcd15-winnt: 64bit, dynamically linked rt with debug info, VS 2017
 x86_64-libcmt14.0-winnt: 64bit, statically linked runtime, Visual Studio 2015
 i686-libcmtd10.0-winnt: 32bit, statically linked rt with debug info, VS 2010
The parity-setup script does detect the availability of Visual Studio versions
along the Windows registry, as well as vswhere.exe since Visual Studio 2017.

Also noteworthy: Parity source code does contain a cygwin/parity.cygport file,
allowing to create Cygwin binary packages. But inclusion into the upstream
Cygwin distro would require someone to maintain these binary packages.

[1] https://github.com/mduft/parity

HTH,
/haubi/