Re: problems with latest Cygwin 1.1

Re: problems with latest Cygwin 1.1

[Carl Thompson]

"Parker, Ron" wrote:

> ...

> This just leaves one link error that I do not have time to resolve
> right now:
> 
> /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../ \
> i686-pc-cygwin/lib/libmin
> gw32.a(main.o)(.text+0x8f):main.c: undefined reference to `WinMain@16'
> collect2: ld returned 1 exit status
> I searched the list, but the "-Wl,-u,WinMain@16" solution that was
> previously mentioned by Mumit Khan does not seem to work in this case.
>  He is unavailable until mid-month and I am just trying to fill in
> where I can while I am waiting on computers at work.

We already have a solution to this problem.  Thanks!  (We basically add a
WinMain() to our library which calls main().  Doesn't work properly when the
library is built as a DLL though because Windows is shared-library
challenged apparently).


> > Also, what happens if I want to use the math library in my app?
> 
> When you compile with the -mno-cygwin switch it picks up the math
> routines automatically from crtldll.dll via -lcrtldll.

OK, I can get rid of "-lm" in the configure script for the Cygwin target.

These workarounds might work if I specify the C++ compile command
explicitely to configure.  Not as nice as it just plain working, but maybe
doable.

Thanks,
Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: problems with latest Cygwin 1.1

[Parker, Ron]

>   gcc -g cet3.cxx -o cet3 -mno-cygwin -lstdc++

> produces the attached copious error output.

If you leave off the -lstdc++ it avoids linking against the libstd++.a which
does require cygwin1.dll.  It will pickup the <stream.h> implementation code
from elsewhere, libmingw.a I believe.  Sorry, I didn't pick up on this in my
earlier mail.

This just leaves one link error that I do not have time to resolve right
now:

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib/libmin
gw32.a(main.o)(.text+0x8f):main.c: undefined reference to `WinMain@16'
collect2: ld returned 1 exit status

I searched the list, but the "-Wl,-u,WinMain@16" solution that was
previously mentioned by Mumit Khan does not seem to work in this case.  He
is unavailable until mid-month and I am just trying to fill in where I can
while I am waiting on computers at work.

> Also, what happens if I want to use the math library in my app?  

When you compile with the -mno-cygwin switch it picks up the math routines
automatically from crtldll.dll via -lcrtldll.

Re: problems with latest Cygwin 1.1

[Carl Thompson]

Chris Faylor wrote:
> 
> On Mon, Jun 05, 2000 at 06:22:05PM -0700, Carl Thompson wrote:

> >...

> >Finally, I don't think it's unreasonable for me to say that compiling
> >C++ apps with g++ should work, especially when it worked in a
> >previous release (b20).
> 
> You're right.  You should definitely ask for your money back.

I didn't mean for it to sound nasty, I just think that it's reasonable that
it should work.

> cgf

Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problems with latest Cygwin 1.1

[Chris Faylor]

On Mon, Jun 05, 2000 at 06:22:05PM -0700, Carl Thompson wrote:
>with this command line
>
>   gcc -g cet3.cxx -o cet3 -mno-cygwin -lstdc++
>
>produces the attached copious error output.  Also, what happens if I want to
>use the math library in my app?  Moreover, this  "solution" requires hacking
>my configure scripts and makefiles when they should work automatically. 
>Finally, I don't think it's unreasonable for me to say that compiling C++
>apps with g++ should work, especially when it worked in a previous release
>(b20).

You're right.  You should definitely ask for your money back.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problems with latest Cygwin 1.1

[Carl Thompson]

"Parker, Ron" wrote:

> ...

> 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.

This doesn't seem to work, unfortunately.  Compiling this test program

   // cet3.cxx
   #include <stream.h>
   main() {
     cerr << "This is a test!" << endl ;
   }

with this command line

   gcc -g cet3.cxx -o cet3 -mno-cygwin -lstdc++

produces the attached copious error output.  Also, what happens if I want to
use the math library in my app?  Moreover, this  "solution" requires hacking
my configure scripts and makefiles when they should work automatically. 
Finally, I don't think it's unreasonable for me to say that compiling C++
apps with g++ should work, especially when it worked in a previous release
(b20).

> ...

> I will also send you the fixed g++.exe if you would like. It is about
> 29KB.

OK, thanks.

Thanks again,
Carl Thompson
/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iostream.o)(.text+0x154): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iostream.o)(.text+0x521): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iostream.o)(.text+0x17c7): undefined reference to `_impure_ptr'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iostream.o)(.text+0x17d8): undefined reference to `_impure_ptr'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(streambuf.o)(.text+0x3e7): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(stdstrbufs.o)(.text+0x46): undefined reference to `_impure_ptr'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(stdiostream.o)(.text+0x16c): undefined reference to `__srget'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x60): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x8d): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x584): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x5d1): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x85d): undefined reference to `_imp___ctype_'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(iovfscanf.o)(.text+0x8b4): more undefined references to `_imp___ctype_' follow

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x194): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x206): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x261): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x390): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x459): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(fileops.o)(.text+0x5b1): more undefined references to `__errno' follow

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(floatconv.o)(.text+0x128d): undefined reference to `__infinity'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libstdc++.a(floatconv.o)(.text+0x13ed): undefined reference to `__errno'

/bin/../lib/gcc-lib/i686-pc-cygwin/2.95.2/libgcc.a(_eh.o)(.text+0x389): undefined reference to `_impure_ptr'

collect2: ld returned 1 exit status

RE: problems with latest Cygwin 1.1

[Parker, Ron]

> 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.

Re: problems with latest Cygwin 1.1

[Carl Thompson]

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?).

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.

Does anybody have an idea what my problem is?

Thank you,
Carl Thompson


"Parker, Ron" wrote:
> 
> > -----Original Message-----
> > From: Carl Thompson [ mailto:cet@carlthompson.net ]
> > Sent: Monday, June 05, 2000 12:43 AM
> > To: cygwin@sourceware.cygnus.com
> > Subject: problems with latest Cygwin 1.1
> >
> >
> > Hello,
> >
> >      I'm having problems using the latest Cygwin release (just
> > downloaded and installed today using today's setup.exe).  If I
> > compile any trivial C++ application with the "-mno-cygwin" option,
> > the compile apparently succeeds but when the application is run it
> > faults.  I am running on Windows 2000.  Using the C compiler to
> > generate executables works fine; just executables compiled using the
> > C++ compiler die.  I have used older versions (1.0) of Cygwin with
> > success.  My development project (the LGPLed FLTK cross platform
> > GUI toolkit) does not require the Cygwin DLL, however it does
> > require the Cygwin build enviroment.
> >
> >      Also, the Insight debugger supplied with the latest Cygwin
> > cannot seem to find / process source files on my system.  When I
> > start up the debugger with an executable compiled with the "-g"
> > flag, it pops up a dialog with a lot of error output apparently
> > related to loading the source file.  The program's source is not
> > displayed, nor does it seem to know the source files' names as
> > normal.  I've used a previous version on a previous version
> > of Cygwin with success.
> >
> >      Are the bugs known and is it known when they will be fixed?  I
> > would rather not go back to 1.0 because I have to heavily modify it
> > to use newer compilers and tools (takes a while).
> >
> >      Please CC me in any responses; I am not on the list.
> 
> I might suggest that you go to the mailing list archives and do a
> search.  Both of these topics have been abused to death on the list in
> the last month.  See http://sourceware.cygnus.com/ml/cygwin/ and
> http://www.delorie.com/archives/ for two different archive interfaces.
> 
> This thread addresses what might be causing your 'fault'.
> 
> http://www.delorie.com/archives/search.cgi?search=Exception+Handling+Broken& ;
> since=month&db=cygwin
> 
> And a search for 'gdb' will yeild enough reading material for the next
> month.
> 
> HTH

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: problems with latest Cygwin 1.1

[Parker, Ron]

> -----Original Message-----
> From: Carl Thompson [ mailto:cet@carlthompson.net ]
> Sent: Monday, June 05, 2000 12:43 AM
> To: cygwin@sourceware.cygnus.com
> Subject: problems with latest Cygwin 1.1
> 
> 
> Hello,
> 
>      I'm having problems using the latest Cygwin release 
> (just downloaded
> and installed today using today's setup.exe).  If I compile 
> any trivial C++
> application with the "-mno-cygwin" option, the compile 
> apparently succeeds
> but when the application is run it faults.  I am running on 
> Windows 2000. 
> Using the C compiler to generate executables works fine; just 
> executables
> compiled using the C++ compiler die.  I have used older 
> versions (1.0) of
> Cygwin with success.  My development project (the LGPLed FLTK 
> cross platform
> GUI toolkit) does not require the Cygwin DLL, however it does 
> require the
> Cygwin build enviroment.
> 
>      Also, the Insight debugger supplied with the latest 
> Cygwin cannot seem
> to find / process source files on my system.  When I start up 
> the debugger
> with an executable compiled with the "-g" flag, it pops up a 
> dialog with a
> lot of error output apparently related to loading the source 
> file.  The
> program's source is not displayed, nor does it seem to know the source
> files' names as normal.  I've used a previous version on a 
> previous version
> of Cygwin with success.
> 
>      Are the bugs known and is it known when they will be 
> fixed?  I would
> rather not go back to 1.0 because I have to heavily modify it 
> to use newer
> compilers and tools (takes a while).
> 
>      Please CC me in any responses; I am not on the list.

I might suggest that you go to the mailing list archives and do a search.
Both of these topics have been abused to death on the list in the last
month.  See http://sourceware.cygnus.com/ml/cygwin/ and
http://www.delorie.com/archives/ for two different archive interfaces.

This thread addresses what might be causing your 'fault'.
	
http://www.delorie.com/archives/search.cgi?search=Exception+Handling+Broken& ;
since=month&db=cygwin

And a search for 'gdb' will yeild enough reading material for the next
month.

HTH

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

problems with latest Cygwin 1.1

[Carl Thompson]

Hello,

     I'm having problems using the latest Cygwin release (just downloaded
and installed today using today's setup.exe).  If I compile any trivial C++
application with the "-mno-cygwin" option, the compile apparently succeeds
but when the application is run it faults.  I am running on Windows 2000. 
Using the C compiler to generate executables works fine; just executables
compiled using the C++ compiler die.  I have used older versions (1.0) of
Cygwin with success.  My development project (the LGPLed FLTK cross platform
GUI toolkit) does not require the Cygwin DLL, however it does require the
Cygwin build enviroment.

     Also, the Insight debugger supplied with the latest Cygwin cannot seem
to find / process source files on my system.  When I start up the debugger
with an executable compiled with the "-g" flag, it pops up a dialog with a
lot of error output apparently related to loading the source file.  The
program's source is not displayed, nor does it seem to know the source
files' names as normal.  I've used a previous version on a previous version
of Cygwin with success.

     Are the bugs known and is it known when they will be fixed?  I would
rather not go back to 1.0 because I have to heavily modify it to use newer
compilers and tools (takes a while).

     Please CC me in any responses; I am not on the list.

Thank you very much,
Carl Thompson

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com