Message-Id:	<200005312207.SAA28835@delorie.com>
Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
From:	"Parker, Ron" <rdparker AT butlermfg DOT com>
To:	Ross Smith <ross DOT s AT ihug DOT co DOT nz>, cygwin AT sourceware DOT cygnus DOT com
Cc:	"'khan AT NanoTech DOT Wisc DOT EDU'" <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)

------_=_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--

- Raw text -