Re: [Mingw-users] ANN: MinGW GCC 4.1.2 binaries installer for Windows

[Keith M. <kei...@to...>]

Giovanni Bajo wrote, quoting me:
[Re: Danny Smith's statement on why he hasn't released GCC-4.x]
>>> OK. I wasn't able to find those messages by searching by either google 

>>> (with or without specific site:, or gmane). It might well be that I 
did 
>>> not search hard enough. Does google index that mingw-users mailing 
list 
>>> at all? That may be part of the trouble.
>>
>> I don't know.  I found this one, with a gmane search:
>> http://article.gmane.org/gmane.comp.gnu.mingw.user/20241
>>
>> (It's quite picky though; I needed to search for "regressions",
>>  written by "danny smith" -- "regression" didn't cut it :-( ).
>
> Well, to find this article, you had to know that the fact that there is 
> no 4.x releases of GCC is related to the number of regressions. This is 
> not something which can be deduced by other means. (In fact, I hope you 
> believe me that I really did try and search infos about official GCC 4.X 

> releases and did not found anything).

I agree that it wasn't as easy to find as I'd hoped it might be.

> This said, the article speaks of generic P1 and P2 regressions, which 
> are valid for *all* platforms (not only MinGW). Those regressions 
> *notwithstanding*, FSF has released GCC. MinGW is of course free to have 

> a more severe policy, but I would disagree with such a choice.

And of course, you are free to disagree.  Personally, I would be
willing to accommodate users who really cannot live without GCC-4.x,
but I am not a GCC developer, and would require the services of a
Release Manager to maintain and support such a release.  At the moment
I rely on Danny, to manage GCC releases for MinGW, and he is not yet
comfortable with the notion of releasing GCC-4.

> Instead, I'd understand if the MinGW release was held while awaiting 
> fixes for severe *mingw-only* regressions (given that FSF currently does 

> not currently consider mingw an important platform for its release 
> criteria). But then, my suggestion is to keep a wiki page with an exact 
> list of all the Bugzilla bugs (mingw-specific, or specifically affecting 

> mingw in a severe form) which are helding the release, so that everybody 

> can know the exact status of the release, and maybe even help out.
>
> Had I found such a list, I would have surely inspected it and see if I 
> could help out somehow.

Please feel free to contribute such a Wiki page; your efforts will
surely be appreciated.  As a starting point, you could use the content
of Danny's earlier message:
| Many of the dllimport fixes in 4.2+ have been backported to 4.1.2.  Two
| significant exceptions
| come to mind:
|
| 1) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31275 (The most recent of
| several reports)
|
| 2) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650 
|
| I don't  know if these are significant for most mingw users, but they
| are significant to my work, so in the absence of further information I
| consider them 'serious'.
|
| Other issues which need to be addressed are 
|
| 1) Throwing exception objects across dll/exe boundaries. 
| 2) C++ strings vs dll's 
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 
|
| These two can be fixed with further hacks to the mingw-specific
| w32-shared-pointer code.  That has become an unacceptable (to me)
| maintenance burden. A libstdc++.dll option would make it soooo much
| easier.
|
| 3) Inefficiencies and backtrace lossage associated with use of SJLJ
| exceptions.  This is a really old bug.
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563.
| Changing to Dwarf2 exceptions is not hard.

And here, Danny throws down the guantlet to *you*:
| If mingw users want an "official" (=="bug-reports are a mingw project
| responsibility") GCC-4.1.2 mingw binary package, please explain why you
| can't wait and why someone besides yourself should spend time on it.

I'll take that a step further, and throw down one of my own: I'd even
be willing to host *your* GCC-4.1.2 release as a MinGW snapshot, along
with all of its supporting sources, on condition that you are willing
to address any support queries relating to it, which are addressed to
this list.

>>> While I respectfully disagree with your release policy (see the rest
>>> of the mail), I would like to thank you for all your feedback. I have 
>>> updated again the webpage, and I hope that you like the new wording 
>>> more. Let me know if you still find incomplete or incorrect.
>>
>> Thanks.  It's better now, although the wording might be construed as
>> mildly inflammatory.
>
> I am mildly annoyed by the fact that there still not even an 
> *unofficial* GCC 4.X binary on the mingw.org (let alone an official 
> release), given that it's really hard to compile GCC,

So, take up my challenge -- provide and maintain it for me.

> and there are very 
> obscure problems like that of relocations (which only few people seem 
> aware of),

And probably fewer still, among the MinGW user community, who even care.

> and that of the MSVCR*.DLL, for which it is incredibly hard 
> to find a good source of information

I don't understand your point here.  MinGW *must* work with the basic
MSVCRT.DLL, which is supplied as an integral component of all current
Win32 OS releases, or is acquired by installation of IE5+; it must
*never* depend on any other version supplied only with Visual Studio,
(or questionably redistributed from any VS release).  The *definitive*
source of information on MSVCRT.DLL is MSDN.

> (and I'm going to update the MinGW 
> wiki about it myself, trying to help out the project).

Please do.  Any useful information contributed to the Wiki is welcome,
but take care to cite only publicly available sources.

> Thus, I'll keep the text as "mildly inflammatory", as long as it does 
> not misrepresent MinGW's official position, and it is sufficiently clear 

> for readers.

Well, it gives the impression that we are intransigently opposed to
releasing any GCC-4.x build in the forseeable future.  That simply
isn't true.  Our resources, all of which are provided on a strictly
voluntary basis, are limited.  We have one individual, (Danny), who is
willing to manage GCC releases; he takes a cautious approach to that,
for reasons which only he can definitively explain.  As a GCC user, I
have no problem with that philosophy; GCC-3.4.5 is perfectly adequate
for my needs, and "if it ain't broke, don't fix it" works for me.
Yes, there are some users who have asked about the possibility of a
forthcoming GCC-4.x release.  Do they really need it?  Only they can
answer that.  Are they willing to step forward, put in the effort, and
help us to create such a release?  Again, only they can answer, but to
date none has taken that step.  Are we ready to release GCC-4.x, in
the absence of such additional voluntary assistance?  Danny has
already answered that with a resounding "not yet".

So, at the risk of seeming inflammatory myself, I'll repeat: you
provide, maintain and support it, and I'll seriously consider hosting
it; beyond that, it's a case of "put up, or shut up".

Regards,
Keith.