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: Chris Faylor Date: Wed, 31 May 2000 19:13:54 -0400 To: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Major bug -- Exception handling broken Message-ID: <20000531191354.A30884@cygnus.com> Reply-To: cygwin AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin AT sourceware DOT cygnus DOT com References: <008501bfcb53$27bac960$a8a11dcb AT ihug DOT co DOT nz> <4 DOT 3 DOT 1 DOT 2 DOT 20000531185749 DOT 03b507f0 AT pop DOT ma DOT ultranet DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4.3.1.2.20000531185749.03b507f0@pop.ma.ultranet.com>; from lhall@rfk.com on Wed, May 31, 2000 at 07:08:41PM -0500 On Wed, May 31, 2000 at 07:08:41PM -0500, Larry Hall (RFK Partners, Inc) wrote: >At 05:54 PM 5/31/00, Ross Smith wrote: >>From: "Parker, Ron" >>>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. >>> >>> [snip] >>> >>> 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. >> >>Cygwin's libm.a is a symlink to libcygwin.a. I'll try replacing it >>with a dummy stub library ... ... nope, that made ld >>crash. > >Hm. All this rings a bell with me. Something very old and very >foggy.... Seems to me I recall that multiple references to libraries >in the link stream always caused Cygwin to crash. I believe the >context of this the last time the issue came up was with Windows >libraries but perhaps the issue is more generic. Also, I recall >discussions which stated that there isn't really a libm.a for Cygwin. >Its all in Cygwin. That would imply that libcygwin.a == libm.a, a >notion that the symlink tends to support. Given all this, its my >impression that libm.a isn't needed, at least in the default case. >Obviously, eliminating libm.a as a default library to link against is >not the complete solution since some packages are going to link against >it explicitly in their makefile and therefore still see problem (unless >the makefile is edited!;-)) Probably we'll need to wait for Mumit to >clarify this whole situation but eliminating the -lm seems a good >work-around for now!;-) You're right that adding libm.a or libc.a to the link line can screw up constructors in g++. I thought that this was solved in the gcc that we're releasing. Guess not. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com