Message-Id: <200005312207.SAA28835@delorie.com> Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: "Parker, Ron" To: Ross Smith , cygwin AT sourceware DOT cygnus DOT com Cc: "'khan AT NanoTech DOT Wisc DOT EDU'" Subject: RE: Major bug -- Exception handling broken Date: Wed, 31 May 2000 17:05:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCB4C.65269A78" ------_=_NextPart_000_01BFCB4C.65269A78 Content-Type: text/plain; charset="iso-8859-1" > > Exception handling in g++ is totally broken in the current Cygwin > > release. Almost any program that uses exceptions crashes: > > > > class Foo {}; > > int main() { > > try { throw Foo(); } > > catch (const Foo&) { return 0; } > > } > > > > $ g++ foo.cpp -o foo > > $ ./foo > > 0 [main] foo 1007 handle_exceptions: Exception: > > STATUS_ACCESS_VIOLATION > > 5052 [main] foo 1007 stackdump: Dumping stack trace to > > foo.exe.stackdump > > I have verified that this is a bug. Mumit Khan, the cygwin > gcc guru, is out > of the country and should be back mid-June. In the mean time > I will see > what I can find. > > For the time being you may work around it by replacing g++ in > the command > line with gcc. That produces a working executable. My best > guess at this > time is that there is a problem with g++ in the specs file. > I will check it > next. My hunch about the specs file was wrong. There are no entries related to g++. However I did track this down to a problem with g++ using libm.a. When I did a: gcc -v foo.cpp -o foo the following was the last line of output: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -o foo.exe /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib/crt0.o -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2 -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../.. /tmp/ccT9VBnq.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc And: g++ -v foo.cpp -o foo yields: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/collect2.exe -o foo.exe /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib/crt0.o -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2 -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../.. /tmp/ccjfPal7.o -lstdc++ -lm -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc The only significant differences here are the -lstdc++ and the -lm. This led to following tests: gcc -v foo.cpp -o foo -lstd++ (OKAY) gcc -v foo.cpp -o foo -lstd++ -lm(BAD) gcc -v foo.cpp -o foo -lm (BAD) So the problem seems to be with libm.a. I did a little more looking around and discovered that g++ should not be linking against -lm. So, I came up with the following patch that at least make g++ able to compile a working version of the trivial test listed above. It looks like a previous patch of Mumit's may have gotten dropped. If you cannot rebuild gcc, I can email a stripped and gzip'd version of the fixed g++. It is only 29,995 bytes. Wed May 31 14:52:18 CDT 2000 Ron Parker (rdparker AT butlermfg DOT com) * i386/cygwin.h (MATH_LIBRARY): Make it null. ------_=_NextPart_000_01BFCB4C.65269A78 Content-Type: text/plain; charset=us-ascii -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com ------_=_NextPart_000_01BFCB4C.65269A78--