Mail Archives: cygwin/2000/06/05/18:37:06
------_=_NextPart_000_01BFCF3E.565AAEBE
Content-Type: text/plain;
charset="windows-1252"
> Thank you for your response. Going through the list, I did
> find a link to
> an updated version of gdb that solved the Insight source
> loading problem
> (will this go into the main distribution soon?).
It's being tested and should become part of "latest" soon.
> However, I did not find anything that addresses my main
> problem of "g++
> -mno-cygwin" does not produce working executables. This does
> not seem to be
> an exception problem as using "-fno-exceptions" makes no
> difference and the
> source uses no exceptions. The whole test program I was compiling was
> simply "main(){}" . If I compile it with "-g" and use the
> working gdb on
> it, it says the program is dying before main() in
> "_size_of_stack_reserve__"
> . Interestingly, if I run "cygcheck" against the executable
> it shows that
> it is using "cygwin1.dll" even though I compiled with "-mno-cygwin" .
> Clearly there is something wrong with the compiler / linker
> when C++ and
> "-mno-cygwin" are used. I am running on Windows 2000.
> Compiling C using
> "gcc" works properly. Also, Cygwin b20 worked. Compiling without
> "-mno-cygwin" works too.
I could refer you back to the same set of messages, but...
Using g++ always causes the application to be linked against libm.a, which
is a symlink to libcygwin.a. The work around is to use gcc with the
-lstdc++ switch, if needed. This will link without libm.a.
http://www.delorie.com/archives/browse.cgi?p=cygwin/2000/05/31/18:07:09
contains more information on the subject. Here is a copy of the patch that
is referred to, since the archive do not keep attachments.
I will also send you the fixed g++.exe if you would like. It is about 29KB.
------_=_NextPart_000_01BFCF3E.565AAEBE
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_01BFCF3E.565AAEBE--
- Raw text -