MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Stephan T. Lavavej]

[DJ Delorie]
> some platforms are supported by groups outside of gcc development,
> who are in general happy with a target that doesn't happen to be
> useful as-is out of the gcc source tree, but would still be
> inconvenienced if that target were deprecated.

However, there are some platforms which are supported by non-gcc developers
and aren't useful as-is from FSF sources, yet the platform's users
desperately wish that gcc would work as-is.

I'm talking about MinGW, which - as far as I can tell - receives fairly
little attention from the gcc developers and the community in general,
despite being the *only* way to produce true Win32 executables that can be
licensed in any manner. From reading the MinGW and gcc mailing lists, I
believe that MinGW exists as a set of patches on a developer's hard drive to
the FSF sources. Thus, if I want to go and build MinGW, I can't, because I
don't have those patches. I have to wait until the MinGW developers release
a compatible set of patches and build the appropriate binaries.  For
example, I'm currently waiting for MinGW 3.3.

The message here is interesting:
http://sourceforge.net/mailarchive/forum.php?thread_id=2280276&forum_id=5119

[Danny R. Smith] 
> The idea is to get all the ming and cygwin local changes into 
> mainstream FSF CVS, so that there is no need for a branch.
> We are getting there.
> Mingw Java developers have been particularly active and the ReactOs
> people have also added a fair chunk.

>> I see these GCC .diff files for every MinGW GCC release.
>> Where are they coming from?
>> On a maintainer's hard drive, perhaps? =)

> Yes, mine, for now.
> But that is not satisfactory from my point of view either.  

>> What specifically keeps these patches from being committed?
 
> Time. Also, many heavy gcc developers have more importnat things to
> review than patches for an unsupported platform like mingw. 
> Cygwin, at least, is considered a secondary platform.
 
Given MinGW's importance as the only real way to run gcc on Windows, I don't
see why it's not even a secondary platform for gcc.

And even if MinGW doesn't become a secondary platform, it would be a great
help if the gcc developers could work on reviewing MinGW patches and getting
them hoovered into the mainstream FSF CVS.

I live in mortal fear that some day the MinGW developers will lose
interest/be hit by a truck/whatever, and gcc will suddenly become unusable
on Windows. Linux is great - I just put it on my second computer - but I
think it's important to keep gcc functional on Windows, if for nothing else
than to act as a gateway for new developers to get into the world of gcc.

Stephan T. Lavavej
http://stl.caltech.edu

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Joe Buck]

> Given MinGW's importance as the only real way to run gcc on Windows, I don't
> see why it's not even a secondary platform for gcc.

Cygwin is of course an option (free for those not impacted by the GPL,
commercial license available for the rest).  However, the rules for
secondary platforms require a capable volunteer to sign up to be the
tester and coordinator for any needed bug fixes.  If a MinGW champion is
willing to take on that role, it will happen.  If not, it won't.

> I live in mortal fear that some day the MinGW developers will lose
> interest/be hit by a truck/whatever, and gcc will suddenly become unusable
> on Windows. Linux is great - I just put it on my second computer - but I
> think it's important to keep gcc functional on Windows, if for nothing else
> than to act as a gateway for new developers to get into the world of gcc.

OK.  What are you willing to do about it?

By that I mean that you, personally, could work to make things better if
you so desire.  You could be downloading CVS versions, running them,
reporting on problems, and asking for help with fixes.

Demanding that active GCC developers help isn't going to do anything;
their plates are already full.

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[DJ Delorie]

> However, there are some platforms which are supported by non-gcc
> developers and aren't useful as-is from FSF sources, yet the
> platform's users desperately wish that gcc would work as-is.

The solution to that, is to make those non-gcc developers gcc
maintainers.

> Given MinGW's importance as the only real way to run gcc on Windows,
> I don't see why it's not even a secondary platform for gcc.

So make Danny the MinGW maintainer for GCC.

> I live in mortal fear that some day the MinGW developers will lose
> interest/be hit by a truck/whatever, and gcc will suddenly become
> unusable on Windows.

Don't forget about Cygwin and DJGPP, which also produce programs that
run under Windows.  Not that I'm putting down MinGW, of course ;-)

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Anthony Green]

On Mon, 2003-05-19 at 15:37, Stephan T. Lavavej wrote:
> I'm talking about MinGW, which - as far as I can tell - receives fairly
> little attention from the gcc developers and the community in general,

Well, I don't know about that.  The gcj maintainers and other
contributors have put a lot of work into 3.3.  I think we were just one
patch short of building out of the box...

http://www.thisiscool.com/gcc33_mingw.htm

Considering the level of interest and activity these past few months,
I'd be really surprised if 3.4 didn't build/work out of the box.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Christopher Faylor]

On Mon, May 19, 2003 at 08:08:57PM -0400, DJ Delorie wrote:
>>However, there are some platforms which are supported by non-gcc
>>developers and aren't useful as-is from FSF sources, yet the platform's
>>users desperately wish that gcc would work as-is.
>
>The solution to that, is to make those non-gcc developers gcc
>maintainers.
>
>>Given MinGW's importance as the only real way to run gcc on Windows, I
>>don't see why it's not even a secondary platform for gcc.
>
>So make Danny the MinGW maintainer for GCC.

I've been offering this to Danny for some time.  He is not interested.

I'm not sure what the problem is here.  Danny has been pretty good about
getting mingw/cygwin changes into the trunk.  Where possible, I approve
the changes as quickly as possible.  From the MAINTAINERS file:

windows, cygwin, mingw  Christopher Faylor      cgf@redhat.com

The existence of a mingw patch set should not be a cause for alarm.
We're working on getting mingw and cygwin aligned with gcc trunk.  For a
while we had a branch in gcc for development but I dropped that due to
time constraint.  However, the merging of changes from the
patches/branch is happening.  It's just happening in volunteer time,
like most free software projects.

I'm not sure why mingw is being talked about as if it was a secondary
platform.  From my point of view it receives a lot of high quality
attention from Danny.

cgf

Re: MinGW (Was Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Christopher Faylor]

On Mon, May 19, 2003 at 09:16:13PM -0400, Nathanael Nerode wrote:
>Patches not getting reviewed in a reasonable amount of time is a known 
>problem, and we're all working on it.  :-/

Patches that are submitted for mingw which are covered by the parts of
gcc that I maintain are reviewed in a reasonable amount of time.

Patches in other parts of the tree get reviewed as fast as any other
patches get reviewed, AFAICT.

Sometimes mingw/cygwin *bugs* in gnats languish however.

I do what I can.  I haven't seen anyone around who was willing to step
in to handle cygwin/mingw issues.

cgf
(windows, cygwin, mingw maintainer)

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Bonzini]

> When building other software packages in Cygwin, there is always the switch
> -mno-cygwin available to disable linking to Cygwin DLLs. *But*, you'll need to
> make sure that the package is not making any Unix-specific calls for it to
> work, which unfortunately, GCC has those fork / exec / kill calls.
>
> Eric

configure should properly detect these as absent when CC="gcc -mno-cygwin".  Moreover,
with -mno-cygwin you don't define __unix__ and __CYGWIN__, but __WIN32__ and
__MSVC_CRT__ (not sure about the spelling of this last one).  The problem is that bugs
in the MinGW port are often bound to show up with -mno-cygwin as well.

Paolo

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[E. Weddington]

On 19 May 2003 at 17:32, Stephan T. Lavavej wrote:

> I'm trying to learn. I've managed to successfully build 3.3 on GNU/Linux,
> but haven't been able to build any version of gcc on MSYS/MinGW (whether
> MinGW-patched or not).

I build a GCC cross for the AVR using MinGW / MSYS with a patch from tarballs 
(no bootstrap). There are some caveats including a bug in the current MSYS that 
affects GCC which is still not fixed yet:

<http://sourceforge.net/tracker/index.php?func=detail&aid=671479&group_id=2435&a
tid=102435>

And unfortunately the patch I use is not a very good one. This biggest issue 
seems to be finding Windows replacements for fork / exec / kill. With Cygwin, 
its run-time environment handles these calls, but the down side is that GCC is 
then linked into the Cygwin DLLs. This is not very useful when distributing a 
binary installation; I'd rather not have to ship an almost 1M DLL just to cover 
3 functions.

> > Don't forget about Cygwin and DJGPP, which also produce programs that
> > run under Windows.  Not that I'm putting down MinGW, of course ;-)
> 
<snip> 
> And Cygwin, well, those applications require the Cygwin DLL to be installed on
> the end user's computer (correct me if I'm wrong).  It's always seemed to me to
> be a good solution if you want to simulate GNU/Linux on a Windows machine, but a
> bad solution if you want to create executables that you can distribute to
> others.

When building other software packages in Cygwin, there is always the switch 
-mno-cygwin available to disable linking to Cygwin DLLs. *But*, you'll need to 
make sure that the package is not making any Unix-specific calls for it to 
work, which unfortunately, GCC has those fork / exec / kill calls.

Eric

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Ranjit Mathew]

Stephan T. Lavavej wrote:
> I'm trying to learn. I've managed to successfully build 3.3 on GNU/Linux,
> but haven't been able to build any version of gcc on MSYS/MinGW (whether
> MinGW-patched or not).
> 
> I don't entirely understand CVS yet and I have no clue how diffs/patches
> work (mechanically, not conceptually). I'm trying to learn, though. When
> MinGW gcc 3.3 is released, I'll see if I can bootstrap it, and I'll report
> any problems I encounter.

In GCC 3.3, things aren't that bad at all for MinGW. Except for
a minor glitch:

     http://article.gmane.org/gmane.comp.gnu.mingw.devel/561

GCC 3.3 builds out of the box (C/C++) for MinGW, and is
quite usable as is.

If you are willing to work on Linux (and I guess you are, since
you have already compiled 3.3 for Linux), you might find this
document that I'd written a while ago, useful for this purpose:

     http://ranjitmathew.tripod.com/phartz/gcj/bldgcj.html

The two step process might seem a bit roundabout but amazingly
is almost twice as fast as a native bootstrap on Windows (for
C/C++/Java)!

If you're not interested in GCJ (Java), leave out the "java"
in "--enable-languages=c,c++,java" in the configure scripts.

If you are however, do get this cross-configury patch for
libgcj before you start:

     http://gcc.gnu.org/ml/java-patches/2003-q2/msg00111.html

If you'd rather wait for the "mingw-local" patchset to also
be published before you venture into this, hang on for a
while longer.

The "mingw-local" patchsets are published to the MinGW SF
repository as soon as a MinGW GCC release is made.

Hope this helps.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: MinGW (Was Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Nathanael Nerode]

Stephan T. Lavavej said:

>The message here is interesting:
>http://sourceforge.net/mailarchive/forum.php?thread_id=2280276&forum_id=5119
>
>[Danny R. Smith] 
>> The idea is to get all the ming and cygwin local changes into 
>> mainstream FSF CVS, so that there is no need for a branch.
>> We are getting there.
>> Mingw Java developers have been particularly active and the ReactOs
>> people have also added a fair chunk.
>
>>> I see these GCC .diff files for every MinGW GCC release.
>>> Where are they coming from?
>>> On a maintainer's hard drive, perhaps? =)
>
>> Yes, mine, for now.
>> But that is not satisfactory from my point of view either.  
>
>>> What specifically keeps these patches from being committed?
> 
>> Time. Also, many heavy gcc developers have more importnat things to
>> review than patches for an unsupported platform like mingw. 
>> Cygwin, at least, is considered a secondary platform.

Patches not getting reviewed in a reasonable amount of time is a known 
problem, and we're all working on it.  :-/

If the patches aren't submitted to gcc-patches@gcc.gnu.org, we can't do 
anything, though.

If they are submitted and get no review in about two weeks, the 
submitter should send a message titled 'unreviewed patch'... that usually
gets people's attention.

There are two types of changes:

* MinGW-specific support changes, which don't affect anyone not using 
MinGW.  For these, we'd probably accept the word of the MinGW developers 
to a certain extent, since they're the experts.  I don't see any reason 
why these wouldn't go in quickly, except really sloppy coding, use of 
deprecated or obsolete constructs, or lack of documentation.

* Changes which may affect builds for other platforms as well.  These 
have to be reviewed quite carefully, of course, but are very welcome 
especially if they're bug fixes.  :-)

--Nathanael

Re: MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

[Stephan T. Lavavej]

[Joe Buck]
> you, personally, could work to make things better if you so desire.
> You could be downloading CVS versions, running them, reporting on
> problems, and asking for help with fixes.

I'm trying to learn. I've managed to successfully build 3.3 on GNU/Linux,
but haven't been able to build any version of gcc on MSYS/MinGW (whether
MinGW-patched or not).

I don't entirely understand CVS yet and I have no clue how diffs/patches
work (mechanically, not conceptually). I'm trying to learn, though. When
MinGW gcc 3.3 is released, I'll see if I can bootstrap it, and I'll report
any problems I encounter.

> secondary platforms require a capable volunteer to sign up to be
> the tester and coordinator for any needed bug fixes.
> If a MinGW champion is willing to take on that role, it will happen.

[DJ Delorie]
> The solution to that, is to make those non-gcc developers gcc maintainers.
> So make Danny the MinGW maintainer for GCC.

Hmm. I'll forward this to him.

I didn't want to give the impression that I'm complaining without being able
to contribute anything useful. I did want to make the gcc developers aware
of the plight of the MinGW community (and probably others).

> Don't forget about Cygwin and DJGPP, which also produce programs that
> run under Windows.  Not that I'm putting down MinGW, of course ;-)

I got started with DJGPP under Win98SE, and that worked great. However,
DJGPP executables under WinXP run in the NTVDM - they aren't truly Win32
executables. For example, they don't get their own process name. This causes
them to (1) run slowly, and (2) not at all in extreme cases. I switched from
DJGPP to MinGW when I found that my particularly memory-allocation-intensive
application was performing pathologically under DJGPP but not under MinGW or
GNU/Linux.

And Cygwin, well, those applications require the Cygwin DLL to be installed
on the end user's computer (correct me if I'm wrong).  It's always seemed to
me to be a good solution if you want to simulate GNU/Linux on a Windows
machine, but a bad solution if you want to create executables that you can
distribute to others.

Thanks.
Stephan T. Lavavej
http://www.nuwen.net