| delorie.com/archives/browse.cgi | search |
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!;-)
Larry Hall lhall AT rfk DOT com
RFK Partners, Inc. http://www.rfk.com
118 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
(508) 560-1285 - cell phone
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |