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

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

All,

With haubi recently retiring from the project, I've taken a close look
at platforms we have in use, and cleaned up a lot of them that we have
absolutely no means to support (any more).  This includes old Darwin and
Solaris releases, entire support for HPUX, AIX, etc.

I've left x64-cygwin and x86-winnt untouched in that process.  However,
x64-cygwin in particular requires a large amount of
(non-trivial/disturbing) patches, basically blocking our merging of the
Prefix overlay into gx86.

It seems to me, x64-cygwin and x86-winnt have no sponsor whatsoever at
this point within Gentoo, or our direct user-base.  Some user that
submitted a lot of patches/fixes on our bugzilla in the past pointed out
that Cygwin is no longer necessary for him due to effortless bootstraps
on "WSL".

So, the inevitable question: who needs x64-cygwin/x86-winnt, and who
would take care of maintaining it?  If noone steps up (I cannot even run
the platform) before Feb 1st 2021, I'll probably continue and drop these
two from Gentoo at some point after that.

Please chime in if you have an opinion, info, interest, etc.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Askar Bektassov (Аскар Бектасов)]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Hi Fabian,

With the advent of WSL, I moved completely out of prefix and now have a
small instance of a *native *Gentoo inside windows.

If MS continues improving its compatibility with Linux, I do not foresee
any scenario where I would be willing to use x64-cygwin/x86-winnt again.
The situation may be different for those still relying on X, though.

Cheers,
--
Askar Bektassov (Аскар Бектасов)
Sent from webmail

For more info, LinkedIn <http://www.linkedin.com/in/askarbektassov>


On Thu, 14 Jan 2021 at 12:38, Fabian Groffen <grobian@gentoo.org> wrote:

> All,
>
> With haubi recently retiring from the project, I've taken a close look
> at platforms we have in use, and cleaned up a lot of them that we have
> absolutely no means to support (any more).  This includes old Darwin and
> Solaris releases, entire support for HPUX, AIX, etc.
>
> I've left x64-cygwin and x86-winnt untouched in that process.  However,
> x64-cygwin in particular requires a large amount of
> (non-trivial/disturbing) patches, basically blocking our merging of the
> Prefix overlay into gx86.
>
> It seems to me, x64-cygwin and x86-winnt have no sponsor whatsoever at
> this point within Gentoo, or our direct user-base.  Some user that
> submitted a lot of patches/fixes on our bugzilla in the past pointed out
> that Cygwin is no longer necessary for him due to effortless bootstraps
> on "WSL".
>
> So, the inevitable question: who needs x64-cygwin/x86-winnt, and who
> would take care of maintaining it?  If noone steps up (I cannot even run
> the platform) before Feb 1st 2021, I'll probably continue and drop these
> two from Gentoo at some point after that.
>
> Please chime in if you have an opinion, info, interest, etc.
>
> Thanks,
> Fabian
>
> --
> Fabian Groffen
> Gentoo on a different level
>

[-- Attachment #2: Type: text/html, Size: 2532 bytes --]

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

[Martin Oberzalek]

Hello Fabian,

> So, the inevitable question: who needs x64-cygwin/x86-winnt, and who
> would take care of maintaining it?  If noone steps up (I cannot even run
> the platform) before Feb 1st 2021, I'll probably continue and drop these
> two from Gentoo at some point after that.
> 
> Please chime in if you have an opinion, info, interest, etc.

we are using a fork from haubi from last year und using  
* x64-cygwin 
* x86-winnt
* x64-winnt

x86-winnt is not so important for us. In fact, maybe we will also switch to WSL for our use case in future...

But now we are using actual cygwin versions and our fork of gentoo. Currently this is only working
with the developer release of the cygwin.dll. What I can do is: testing the gentoo prefix stack with 
this upcomming new cygwin release (when its released) and give some feedback. If I can get it working I would update

https://wiki.gentoo.org/wiki/Prefix/Cygwin

Regards, Martin

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

Hey Martin,

On 18-01-2021 06:04:45 +0100, Martin Oberzalek wrote:
> 
> Hello Fabian,
> 
> > So, the inevitable question: who needs x64-cygwin/x86-winnt, and who
> > would take care of maintaining it?  If noone steps up (I cannot even run
> > the platform) before Feb 1st 2021, I'll probably continue and drop these
> > two from Gentoo at some point after that.
> > 
> > Please chime in if you have an opinion, info, interest, etc.
> 
> we are using a fork from haubi from last year und using  
> * x64-cygwin 
> * x86-winnt
> * x64-winnt
> 
> x86-winnt is not so important for us. In fact, maybe we will also switch to WSL for our use case in future...

Ok, I thought *-winnt targets were native Windows code, apparently WSL
is too?  (I'm just learning here, I guess.)

> But now we are using actual cygwin versions and our fork of gentoo. Currently this is only working
> with the developer release of the cygwin.dll. What I can do is: testing the gentoo prefix stack with 
> this upcomming new cygwin release (when its released) and give some feedback. If I can get it working I would update
> 
> https://wiki.gentoo.org/wiki/Prefix/Cygwin

I'm trying to understand what this means.  I'm sure/certain the current
tree doesn't work for Cygwin.  This means I anticipate you'll have to
patch/fix a lot of packages for it.  Would it be more useful to use an
overlay for Cygwin instead?

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Sid Spry]

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.

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

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?

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

[Martin Oberzalek]

Hi Fabian,

Am Montag, den 18.01.2021, 09:48 +0100 schrieb Fabian Groffen:

> On 18-01-2021 06:04:45 +0100, Martin Oberzalek wrote:
> > 
> > > So, the inevitable question: who needs x64-cygwin/x86-winnt, 

> Ok, I thought *-winnt targets were native Windows code, apparently WSL
> is too?  (I'm just learning here, I guess.)

You are right, *-winnt is windows native and might be important when
compiling on WSL via a compiler wrapper like parity/or other helper tool with eg: visual studio  

> > But now we are using actual cygwin versions and our fork of gentoo. Currently this is only working
> > with the developer release of the cygwin.dll. What I can do is: testing the gentoo prefix stack with 
> > this upcomming new cygwin release (when its released) and give some feedback. If I can get it working I would update
> > 
> > https://wiki.gentoo.org/wiki/Prefix/Cygwin
> 
> I'm trying to understand what this means.  I'm sure/certain the current
> tree doesn't work for Cygwin.  This means I anticipate you'll have to
> patch/fix a lot of packages for it.  Would it be more useful to use an
> overlay for Cygwin instead?

I agree, maybe this would be a good solution.

Greetings, Martin

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

[Martin Oberzalek]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hi Fabian,

Am Montag, den 18.01.2021, 09:48 +0100 schrieb Fabian Groffen:

> On 18-01-2021 06:04:45 +0100, Martin Oberzalek wrote:
> > > So, the inevitable question: who needs x64-cygwin/x86-winnt, 
> Ok, I thought *-winnt targets were native Windows code, apparently WSL
> is too?  (I'm just learning here, I guess.)

You are right, *-winnt is windows native and might be important when
compiling on WSL via a compiler wrapper like parity/or other helper tool with eg: visual studio  

> > But now we are using actual cygwin versions and our fork of gentoo. Currently this is only working
> > with the developer release of the cygwin.dll. What I can do is: testing the gentoo prefix stack with 
> > this upcomming new cygwin release (when its released) and give some feedback. If I can get it working I would update
> > 
> > https://wiki.gentoo.org/wiki/Prefix/Cygwin
> 
> I'm trying to understand what this means.  I'm sure/certain the current
> tree doesn't work for Cygwin.  This means I anticipate you'll have to
> patch/fix a lot of packages for it.  Would it be more useful to use an
> overlay for Cygwin instead?

I agree, maybe this would be a good solution.

Greetings, Martin

[-- Attachment #2: Type: text/html, Size: 1947 bytes --]

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

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

Hi Martin,

On 19-01-2021 07:58:00 +0100, Martin Oberzalek wrote:
> > > gentoo prefix stack with
> > > this upcomming new cygwin release (when its released) and give some feedback. If
> > > I can get it working I would update
> > >
> > > https://wiki.gentoo.org/wiki/Prefix/Cygwin[1]
> >
> > I'm trying to understand what this means.  I'm sure/certain the current
> > tree doesn't work for Cygwin.  This means I anticipate you'll have to
> > patch/fix a lot of packages for it.  Would it be more useful to use an
> > overlay for Cygwin instead?
> 
> I agree, maybe this would be a good solution.

I'm looking for who would maintain Cygwin/Windows, and how.

Currently there is a lot of remnants of Cygwin, but also decay.  Python
for instance got its Cygwin patches dropped (they didn't apply, and we
had to move on for security and other reasons), hence I know for sure
that Cygwin support is virtually non-existant in the current tree.

I don't want to destroy the work of others, but at the current state, I
cannot maintain Cygwin or Windows (nor do I have incentive to do so).
With haubi retiring from the project, there's officially no Gentoo
developers working on this.

If a separate overlay or fork is the way to go, we can see if we can get
such repo on Gentoo hardware and set it up, turn Cygwin into a proper
sub-project or something, and move anything necessary there as not to
hold back the Prefix migration of whatever's left back into the main
gentoo repository.

Thanks,
Fabian


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

With the lack of support, and bitrot in the tree, I see no other
option but to remove x64-cygwin from the tree.

I'll do so in the coming weeks.

Fabian


On 21-01-2021 21:40:51 +0100, Fabian Groffen wrote:
> Hi Martin,
> 
> On 19-01-2021 07:58:00 +0100, Martin Oberzalek wrote:
> > > > gentoo prefix stack with
> > > > this upcomming new cygwin release (when its released) and give some feedback. If
> > > > I can get it working I would update
> > > >
> > > > https://wiki.gentoo.org/wiki/Prefix/Cygwin[1]
> > >
> > > I'm trying to understand what this means.  I'm sure/certain the current
> > > tree doesn't work for Cygwin.  This means I anticipate you'll have to
> > > patch/fix a lot of packages for it.  Would it be more useful to use an
> > > overlay for Cygwin instead?
> > 
> > I agree, maybe this would be a good solution.
> 
> I'm looking for who would maintain Cygwin/Windows, and how.
> 
> Currently there is a lot of remnants of Cygwin, but also decay.  Python
> for instance got its Cygwin patches dropped (they didn't apply, and we
> had to move on for security and other reasons), hence I know for sure
> that Cygwin support is virtually non-existant in the current tree.
> 
> I don't want to destroy the work of others, but at the current state, I
> cannot maintain Cygwin or Windows (nor do I have incentive to do so).
> With haubi retiring from the project, there's officially no Gentoo
> developers working on this.
> 
> If a separate overlay or fork is the way to go, we can see if we can get
> such repo on Gentoo hardware and set it up, turn Cygwin into a proper
> sub-project or something, and move anything necessary there as not to
> hold back the Prefix migration of whatever's left back into the main
> gentoo repository.
> 
> Thanks,
> Fabian
> 
> 
> -- 
> Fabian Groffen
> Gentoo on a different level



-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]