From: Danny S. <dan...@cl...> - 2007-03-20 10:13:29
|
> >> > >> Neither MinGW nor Cygwin has yet released a gcc-4.x port. The > >> reason, AIUI, is that there are still too many regression errors > >> to meet their standards of reliability. > > > > It's incredibly hard to find such an information around. Do you have > > a pointer to a place where this has been publicly discussed? > > It has been discussed several times, in recent months, on this very > list; please search the archives. > 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. 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 shuld spend time on it. Danny |
From: Danny S. <dan...@cl...> - 2007-03-21 10:19:33
|
Bob Rossi > > > Is there are development community that does support for the mingw > release of GCC because they receiving contributions/funding to do so? > I'm not in a position to offer this funding (at the moment), but I am > curious about the infrastructure. CodeSourcery has contributed code to improve mingw32. I believe they provide commercial support for a mingw-hosted toolchain, but you should go to there web page to see for yourself what they are up to. They have a 4.1-based branch in SVN which contains many mingw-local patches I am aware of other commercial interests in mingw. If you look in the GCC changelogs, you will even see some an @microsoft.com email address. Donn was author of the MS bitfields option. Personally, I receive no funding nor am I soliciting such. Danny > Thanks, > Bob Rossi > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Brian D. <br...@de...> - 2007-03-20 10:18:44
|
Danny Smith wrote: > maintenance burden. A libstdc++.dll option would make it soooo much > easier. That would be nice, but I'm sure you'll get complaints from those that couldn't possibly live with the horror of distributing a DLL and would want to be able to statically link everything, nevermind the performance. Brian |
From: Greg C. <chi...@co...> - 2007-03-20 14:54:22
|
On 2007-3-20 10:14 UTC, Danny Smith wrote: > > 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'. Okay, here's some further information from one MinGW user. The short version is that several of these things are serious for me, too. The first is marked as a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826 whose crucial line seems to be: extern __attribute__((dllimport)) struct ssss vvvv[]; I avoid exporting data from dlls, because I've found so many problems with it over the years (not just with gcc) that are easily prevented by exporting functions to access the data instead. However, some third-party libraries rely on exporting data (IIRC, libxml2 does), so it's a serious problem for me if it doesn't work. The second [simplified] struct base { __attribute__((dllimport)) virtual ~base(); // Does not have a const address }; uses another construct that I've learned to avoid. The only things I export are whole classes struct __attribute__((dllimport)) base {...}; and standalone functions--never individual member functions. I don't think I've noticed third-party libraries trying to export some member functions but not others, so I'd guess this one might not trouble me, though I wouldn't bet a whole lot of money on that. > 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. I'd certainly call these serious matters as well. The first is one of those things that people just expect to work: e.g., a GUI library in a dll calls back into an application, and the callback can throw an exception. I think the second underlies problems I've encountered when trying to use a malloc debugger on code that passes std::string instances across a dll boundary. Report 24196 was filed for gcc-3.4.4, so I guess it's not a version 4-versus-3 regression, but the issue is rather that maintaining old hacks is too costly--and a shared libstdc++ would of course be preferable for other reasons as well. > 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. I wouldn't mind moving from gcc-3.x with SJLJ to gcc-4.x with SJLJ as an incremental step, but the issue, as discussed above, is the burden of maintaining workarounds for exceptions crossing dll boundaries. Of course, though, dwarf2 exceptions would be preferable. > 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 shuld spend time on it. I can't. That's why I haven't built gcc-4 myself despite available instructions like http://mingw.org/MinGWiki/index.php/How%20to%20Compile%20GCC%204.1 What I really care about is C++, and Fortran users might feel otherwise, but I don't know a compelling reason to use version 4 (until it's more stable on msw) when version 3 is so strong. Faster compiles, better optimization, and the other improvements I've heard of are important incremental gains, but I'd rather wait for them than have to stop using dlls. |