Mail Archives: cygwin/2000/05/31/19:14:47
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" <rdparker AT butlermfg DOT com>
>>>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 ... <tries it> ... 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
- Raw text -