On 9/20/2010 11:31 AM, Bob Friesenhahn wrote:
> On Sun, 19 Sep 2010, Charles Wilson wrote:
>> MinGW/MSYS:
>> old -- All 122 tests passed (2 tests were not run)
>> new -- 108 tests behaved as expected.  12 tests were skipped.
> 
> With Charles Wilson's assistance, I updated my MinGW environment to the
> latest, but using the latest TDM GCC 4.5.1 compiler (only C & C++
> supported).
> 
> These were the results:
> 
> ERROR: 102 tests were run,
> 6 failed (4 expected failures).
> 18 tests were skipped.
> 
> The test which failed (twice) was the C++ exception handling test.
> Similar tests also failed in the GraphicsMagick test suite so it seems
> that C++ exceptions are unreliable with this compiler.

This is really strange.  TDM's builds include special support
*specifically* addressing C++ exception handling when linking against
the static libstdc++ (and, IIUC, linking against the shared libstdc++
Just Works(tm) for both TDM and mingw.org compilers).

IIRC, TDM's compilers link against static libstdc++ by default, and
mingw.org's link against the shared libstdc++ by default -- but I'll
need to double check that.

Bob, if I were you I'd raise this as a bug on TDM's sf page:

http://tdm-gcc.tdragon.net/bugs
http://sourceforge.net/tracker/?group_id=200665&atid=974439

because if it "works" with mingw.org, but fails with TDM...well, that's
a TDM bug, since John E. attempts to allow working
exceptions-across-dll-boundaries for BOTH -static-libstdc++ and
-shared-libstdc++. (Note that mingw.org's g++ WILL fail to propagate
exceptions across the DLL boundary unless -shared-libgcc, which is the
default for -shared-libstdc++, which itself is the default.  Not sure
about -static-libstdc++ with -shared-libgcc, but -static-libstdc++
-static-libgcc is right out.  However, since it *works* with mingw.org,
I don't think a screwup related to these flags is the culprit.)

> As a side note, I find that the GNU make delivered with current MinGW is
> at least 60X slower than before.  It takes GNU make 2.5 minutes before
> it does any actual work (while building GraphicsMagick), which
> represents most of the compilation time with the previous make.  A
> one-year old Cygwin make takes maybe 1.5 seconds to start working when
> given the same environment.

And for this, I'd appreciate it if you could open a bug at mingw.org's
tracker:
http://sourceforge.net/tracker/?group_id=2435&atid=102435

--
Chuck


_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool

Reply via email to