From: Doug S. <dsc...@ro...> - 2009-02-11 07:30:44
|
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 > Min...@li... > > 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 > > |