Thanks Charles, A most excellent status on the state of mingw gcc. This
is something I can plan with.
And yes, I'm top posting. Get over it.
Doug.
Charles Wilson wrote:
> Weddington, Eric wrote:
>
>> Doug wrote:
>>
>>> Well, I didn't really want to say too much here. Being a
>>> project lead of
>>> an open source project myself I know how hard it is to get
>>> volunteers to
>>> contribute. I also know how important it is to build
>>> relationships with
>>> the people in my community so that they feel their contributions are
>>> appreciated, including suggestions on how to improve things.
>>> Suggestions
>>> do at times lead to real contributions. I just fear that people are
>>> being driven away from contributing. And that's too bad.
>>>
>
> Well, I didn't mean to poor gasoline on this fire -- or to discourage
> Doug (http://cdtdoug.blogspot.com/2009/02/mingw-frustrations.html) --
> but I had to call 'em as I saw 'em.
>
> Apparently the medical issues thing has been going around lately; I've
> been dealing with the same for almost a year now -- that's part of the
> explanation for the marked dropoff in my participation. The other is
> that I no longer use mingw/eclipse daily as part of my paying gig; so,
> less incentive to scratch any itches.
>
> But, to sum up my *personal opinion* on the state of mingw-gcc...
>
>
>> I thought this thread was started
>> with intent of just simply trying to find out the status of the gcc
>> 4.3.0 port.
>>
>
> 1) There has been a recent flurry of activity on the main gcc lists,
> gearing up for the 4.4.0 release. This includes various build fixes and
> some runtime/regression fixes for both cygwin and mingw.
>
> 2) Most of these are driven by Danny (who is still active "over there",
> just not "over here"), Kai Teitz (who is mostly focused on 64bit issues)
> and by Dave Korn, the guy who maintains the cygwin gcc packages. (Dave
> is not a *gcc* maintainer for cygwin -- that is, unlike Danny he can't
> approve patches for gcc, but can only update gcc svn after receiving a
> "real gcc maintainer's" approval. However, he is cygwin's gcc package
> release manager, so he could apply custom patches to *cygwin's* gcc
> packages if he wanted to.) Aaron LaFramboise was responsible for a
> number of fixes that went into the to-be-4.4 gcc last summer and early
> fall, but has been silent since then.
>
> 3) A lot of the effort has been going into build fixes, getting shared
> runtime libraries built/working, and getting dwarf-2 exception handling
> working correctly.
>
> 4) Dave Korn's plan for going forward -- on cygwin -- is to ensure that
> 4.4.0 has reasonable behavior "upstream", and then hack 4.3.x with
> "custom" patches to make it build in such a way that we do not see ABI
> issues between his 4.3.x cygwin releases, and any eventual 4.4.x ones.
> For instance, gcc-HEAD (what will be 4.4.0 RSN) will build a libgcc DLL
> on cygwin named
> cyggcc_s-1.dll (dw2 eh)
> cyggcc_s-sjlj-1.dll (sjlj eh)
> but, at present, if you can get it to build a libgcc DLL at all, 4.3.x
> makes one named
> libgcc_s-1.dll (no matter what eh model)
> This is bad, for a number of reasons -- not least, it conflicts with
> mingw's libgcc_s-1.dll! So, Dave's to-be-released
> in-the-next-week-or-so gcc-4.3.x package for cygwin has some really ugly
> local patches so that it, too, will have
> cyggcc_s-1.dll (dw2 eh)
> cyggcc_s-sjlj-1.dll (sjlj eh)
>
> NOTE: gcc-HEAD, when built for mingw with shared libgcc, will create:
> libgcc_s-sjlj-1.dll (sjlj eh)
> libgcc_s-dw2-1.dll (dw2 eh)
> See note below concerning tdm versions.
>
>
> NOTE2: the current "official" mingw test release of 4.3.x of 20080502
> vintage, is sjlj and includes
> libgcc_s_1.dll
> This will differ from the name of the sjlj runtime provided by 4.4.x
> releases.
>
> I'd recommend that, if a mingw 4.3.x package were put into official
> release, that it include "really ugly local patches" to make it behave
> like gcc-HEAD as far as the runtime DLL names are concerned. If the
> "ugly hack" from 3.4.5 is included -- then that's a different ABI and
> the DLL SO version -- if shared runtimes are even provided in that case
> -- should be bumped to -2 or something.
>
> According to Dave
> (http://cygwin.com/ml/cygwin-apps/2009-02/msg00045.html), on cygwin at
> least, gcc-4.3.x (with local cygwin patches), and gcc-4.4.x (more or
> less stock svn-HEAD), both /now/ work pretty well in either dw2 or sjlj
> varieties, assuming shared runtime libraries. (gcc, g++, gfortran, objc,
> objc++, java). Ada still has some issues, but Dave is confident he can
> get those kinks resolved in short order.
>
> I *think* the same is true for mingw versions, for lesser or greater
> amounts of "really ugly local patches". The thing is, unless you want to
> give your users a really nasty surprise, you have to worry A LOT about
> ABI compatibility issues (and DLL naming, for shared runtimes).
>
> 5) When used with static runtimes (which seems to be preferred by mingw
> users), there still exists a problem with throwing exceptions from a
> userland DLL and catching it in (an application or another DLL). This is
> unsolved. tdragon has a forward port of Danny's original (and disavowed)
> hack in 3.4.x -- but this means that the ABI of code compiled with
> tdragon's compiler and code compiled with stock gcc (or a future stock
> gcc that has "a real fix" for the issue) won't interoperate. If all
> client code is self-build using the same compiler (e.g. MinGWPorts, or
> just "do it the hard way") -- then this won't matter to you. Aaron was
> working on a plan to address this issue ("as discussed with KT and
> VR"??) but AFAICT nothing came of it.
>
> My advice: after sufficient discussion, the mingw project has three choices:
> a) "if you want working exception handling, use -shared-libgcc"
> b) Find Aaron, KT(?), and VR(?) and convince them to continue --
> or at least publish -- their work/discussions/ideas about this,
> and git-er-done.
> c) Officially adopt Danny's disavowed patch as ported by tdragon,
> and accept that ABI as "the" ABI for mingw.
> Me, I'd lean towards (a) but mingw users seem allergic to distributing
> "extra" DLLs (c.f. whining about mingwm10.dll). Also, there will
> undoubtedly be issues with 27 different copies of libgcc_s-sjlj-1.dll
> floating around on the same system -- unless we are very careful about
> ABI compatibility. (Does libgcc suffer from the "you can't have more
> than one of me installed" problems that cygwin1.dll does? I don't think
> so --- but I'm not sure.)
>
> 6) PR24196 is an issue with C++ std::strings that can be solved in
> several ways:
> a) use shared libgcc and libstdc++
> b) if using static runtimes, then configure using
> --enable-fully-dynamic-string. This is what tdragon's builds do.
> c) if using static runtimes, apply a patch similar to the one at the
> bugzilla entry:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
> This is what cygwin's 3.4.5 builds do.
>
> I'm not sure about mingw-official 3.4.5. Note that (b) represents an
> ABI change from "stock" gcc. (c) preserves the library ABI, but it is
> unclear whether code copied by stock gcc and code compiled with a
> (c)-modified gcc can interoperate.
>
> 7) dw2 is faster, but leads to problems catching exceptions thrown
> across "foreign frames". That is, suppose you have a callback compiled
> using gcc, and you pass that callback to a w32api function -- as is
> common in GUI event-driven programming. Then, suppose that your
> callback throws an exception. The stack begins to unwind from your
> callback, into the w32api function. But THAT function -- compiled by
> Redmond presumably -- doesn't have the dw2 unwinding information. So,
> the unwinding data gets corrupted, and skips right past whatever 'catch'
> statement you expected to get control. Instead, the stack unwinds all
> the way up to main, and your program terminates with an unhandled
> excpetion error, and a Win32 popup ("This application has terminated in
> an unexpected manner...")
>
> This is bad.
>
> Again, Aaron spent MOST of his time during his google Summer of Code
> project attempting to address this issue, but:
>
>> A large amount of work was spent here, but there are hard problems
>> that need more work to resolve. I wrote a few prototype unwinders,
>> which I intended to submit, but they turned out to have problems that
>> I have not yet resolved. I will continue working on this issue.
>>
> I don't know if anything ever came of this.
>
> Therefore, most mingw users would probably prefer the slower -- but more
> reliable for w32 gui/event-driven programming -- sjlj variant.
>
> 8) About tdragon's 4.3.0 releases. The current ones (4.3.2-based,
> released in december) -- do not contain shared runtime libraries at all.
> They rely on the 3.4.x hack for exception handling across DLL
> boundaries. However:
>
>> The TDM-2 release of GCC 4.3.0 incorporated experimental builds of
>> libgcc and libstdc++ as DLLs in order to allow exceptions to be
>> thrown out of DLLs. With the more recent releases this has been
>> dropped in favor of a ported version of 3.4.5's shared memory patch,
>> because of various problems encountered in the DLL versions. (Once
>> these problems are solved, the DLL versions will be included again.)
>>
>> Therefore, you no longer need to add any additional command-line
>> options to throw exceptions out of a DLL. You should, however, still
>> add "-mthreads" to the command line any time you throw exceptions in
>> a multi-threading context.
>>
>> The ported exceptions/DLLs patch is experimental and has only
>> received limited testing, so please report any bugs you encounter in
>> throwing exceptions that are not present in the official MinGW 3.4.5
>> release.
>>
> Some early tdm 4.3.0 versions (circa May/June 2008) -- which DID include
> shared runtimes -- included them under the names
> libgcc_tdm_1.dll (sjlj)
> libstdc++_tdm_1.dll (sjlj, c++)
> ... etc ...
> libgcc_tdm_dw2_1.dll (dw2)
> libstdc++_tdm_dw2_1.dll (dw2, c++)
> ... etc ...
> So, the good news there is (a) tdragon ensured that his dw2 and sjlj
> builds didn't "conflict" -- unlike stock 4.3.0 (when you teased it into
> building shared runtimes at all), and (b) tdragon's runtime DLLs won't
> conflict with future "stock" 4.4.x shared runtimes. But, as he said,
> these early runtime DLLs had some issues, and he eventually retired them
> in favor of porting Danny's "hack" from 3.4.5.
>
> Now, these May/June builds were done *before* many of Aaron's fixes went
> into SVN. Also, they were done long before Dave Korn's recent efforts
> at getting shared runtimes to work properly on cygwin. I believe -- but
> do not know -- that those fixes will also benefit mingw shared-runtime
> builds.
>
> All current 4.3.x tdm builds include this bug:
>
>> Classes with virtual inheritance (in the class itself or any ancestor
>> class), an inline constructor or destructor, and the "dllimport"
>> attribute will cause an ICE in maybe_emit_vtables. It is technically
>> incorrect for any function definition to be marked dllimport, so this
>> situation typically implies brittle code that should be fixed. See
>> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654>.
>>
> But that has been fixed in gcc-svn-HEAD and gcc-svn-4.3.
>
> tdragon's builds do not provide java.
>
> =======================================
>
> To sum up: IMO none of the test releases "out there" are quite ready for
> prime time -- or at least, not without discussion of some of the
> implications involved in their adoption, like de-facto ABI modifications
> and DLL naming conventions.
>
> P.S. I could also sum up the status of the MSYS environment, and
> categorize the "up to date"/"most recent" packages for a "complete"
> installation, but I'm afraid I'd digress into unbecoming blue language.
> So we'll save that for later.
>
> --
> Chuck
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
> _______________________________________________
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.
>
> Most annoying abuses are:
> 1) Top posting
> 2) HTML/MIME encoded mail
> 3) Improper quoting
> 4) Improper trimming
>
>
|
