From: dashesy <da...@gm...> - 2011-06-03 18:09:25
|
> On 6/3/2011 3:45 AM, JonY wrote: >> On 6/3/2011 11:10, Xiaofan Chen wrote: >>> If I am only dealing with C and not C++, there should be no >>> problems, right? >>> >> >> You should have no problems when dealing code purely in C. > > However, when dealing with C++ you *will* have problems. > > Furthermore, even in C, if you link against the shared libgcc, then > you'll have TWO different libgcc dependencies: one on > libgcc_s-sjlj-1.dll (or maybe it is called libgcc_s-1.dll?) and one on > libgcc_s-dw2-1.dll. This may work (or maybe not; unsure) but it surely > isn't a good idea... > >>> And any chance that those Linux MinGW cross compiler packagers >>> will also follow the MinGW's configuration. Anyway, I consider >>> MinGW.org to be the official place of MinGW GCC so they should >>> follow, right? >>> >> >> Yes, I agree that they should be following the path outlined by >> mingw.org when using mingw.org material. >> >> Note that mingw-w64 uses and strongly encourages sjlj for both >> 32bit/64bit port on purpose for reasons unrelated to the original mingw.org. > > The correct thing to do is to push a change to upstream gcc, so that dw2 > become the default for the i*-pc-mingw32 triple (leaving sjlj as the > default for *-w64-mingw32). > I remember when there was no mingw-get I started with a TDM package for mingw, it took me sometime to understand mixing dw2 created QT libraries with sjlj was not a good idea. Sure mixing compilers is also not a good idea, but aren't OS dlls already compiled by visual studio? Following this mailing list closely I have learned the difference between dw2 and sjlj and why we have two versions in the first place, but this question is lingering: How is the exception handling done by visual studio? Doesn't it make sense to have a platform specific implementation which resembles/conforms to the native OS approach? What happens (depending on dw2 or sjlj) if an exception is raised across an OS dll (I am not talking about just some dll of the web) > The linux distributors are just using the gcc defaults, and are assuming > that is the right thing to do -- normally, they'd be correct. > > In this case, we haven't pushed the change upstream, nor criticized the > linux distributors, because we haven't yet achieved the *advantages* > that dw2 is *supposed* to achieve for us -- faster java, ada. None of > our 4.x compilers have even supported java because it still seems > broken, and the upcoming 4.6.0 mingw is going to have to (temporarily) > drop Ada, because it's broken upstream (apparently? for both mingw32 and > mingw64). > > All we have are the disadvantages: you can't pass dw2 callbacks to > w32api functions... > > I was happy to see some queries on the list about getting gcj working in > 4.6.0, but a little disappointed to see that Cesar didn't respond. > Cesar -- you've got some manpower volunteering... > > -- > Chuck > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/quest-dev2dev2 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > thanks dashesy |