-mno-cygwin: STATUS_STACK_OVERFLOW before main

-mno-cygwin: STATUS_STACK_OVERFLOW before main

[salvador]

Hi!

  I have an application that compiles fine using Mingw32. When I try to compile
it using Cygwin B20.1 (adding -mno-cygwin and -lmingw32 -lcrtdll) I get an
executable, but it dies before reaching main with an STATUS_STACK_OVERFLOW
error.
  I tried with --stack XXXX without luck (same crash in same place).
  My questions:

1) What's status stack?
2) Anybody knows what could be the source of this problem?

  I also saw the program loads cygwin1.dll, is that correct for a mingw32
application generated by cygwin tools or is the result of some mess from my
part?

  I also tried using the libraries and headers from the Mingw32 copy that
generates a valid exe and got the same result.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft@usa.net set@computer.org
                    set@ieee.org set-soft@bigfoot.com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013




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

Re: -mno-cygwin: STATUS_STACK_OVERFLOW before main

[salvador]

Earnie Boyd wrote:

> Ok, you've convinced me to write a page on mixing Cygwin and Mingw tools.
> It'll take a little while to get up though.

Thanks.

> It sounds to me that you need to check out the Mingw list at
> http://www.eGroups.com/group/mingw32 for pointers to native ports of these
> tools.

Ok, I'll do it.

Greetings, SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft@usa.net set@computer.org
                    set@ieee.org set-soft@bigfoot.com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013




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

RE: -mno-cygwin: STATUS_STACK_OVERFLOW before main

[Earnie Boyd]

Ok, you've convinced me to write a page on mixing Cygwin and Mingw tools. 
It'll take a little while to get up though.

It sounds to me that you need to check out the Mingw list at
http://www.eGroups.com/group/mingw32 for pointers to native ports of these
tools.

Earnie.

--- salvador <salvador@inti.gov.ar> wrote:
> fieldhouse@logica.com (Dirk Fieldhouse) wrote:
> 
> 
>      On Tue, 01 Feb 2000 12:47:52 -0300, salvador <salvador at inti dot gov
>      dot ar> wrote:
> 
>      > I have an application that compiles fine using Mingw32. When I
>      > try to compile it using Cygwin B20.1 (adding -mno-cygwin and
>      > -lmingw32 -lcrtdll) I get an executable, but it dies before
>      > reaching main with an STATUS_STACK_OVERFLOW error.
>      >
>      >  I tried with --stack XXXX without luck (same crash in same
>      > place).
>      >...
> 
>      Check your include and link paths. Your supposed mingw32 app is
>      obviously not one.
> 
>      A cygwin installation can easily get confused about a mingw32 target
>      because some #define or library reference may be accidentally resolved
>      against the cygwin include/library files which may follow the mingw32
>      ones in the search paths. This is almost certainly the problem here.
>      Is your program C++ or C - I have seen this with C++ in the past ?
> 
> 
> C++
> 
>      There is some confusion (for me at least) about which files are usable
>      in both targets - those for the Windows OS (.h and lib*.a) ought to be
>      OK.
> 
>      I guess the appropriate resolution of this is for the -mno-cygwin
>      specs to select a different set of paths and use -nostdinc (and the ld
>      equivalent) or similar to avoid picking up cygwin stuff from
>      well-known locations like /usr/include - or to be sure that you don't
>      put cygwin stuff in any of these places.
> 
> I tried renaming all the lib and include directories from Cygwin (just left
> lib/gcc...) and adding the -I and -L settings to pick the Mingw32 stuff from
> separated directories without luck. I used -H to be sure I was picking the
> right
> headers.
> Perhaps I still doing some thing wrong.
> 
> Now I'll explain what I want to do so perhaps somebody can give me an idea:
> 
> I'm currently maintinaing a port of Turbo Vision to gcc. I have the DOS and
> Linux targets working very well (they have all the needed GNU tools). Now a
> user
> contributed a Win32 part, it compiles with Mingw32 (you just need the Mumit
> Khan
> big file installed with gcc/binutils/run-time). It also compiles with MSVC,
> but
> I don't have much interest in this detail ;-). Now I want to integrate the
> Win32
> target to the configuration process, it uses common GNU tools (rm, cp, mv,
> install, uname, sh, etc.) and Perl. None of this goodies are in the Mingw32
> distribution so I taked a look to Cygwin, it only lacks Perl (which is a huge
> drawback from my point of view, download the huge ActivePerl separatle isn't
> quite nice). So I tried to compile with Cygwin and quickly found it is POSIX
> and
> lacks a lot of things used by the Mingw32 target, I can add a Cygwin version,
> after all the code compiles for Linux, but I don't have the time. Then
> looking
> in the directories and specs files I found the -mno-cygwin trick. So I tried
> it,
> but even when all compiles and links fine the exe dies.
> So currently I have a setup that works, but is quite messy, the user needs:
> 
> 1) Mingw32 (Khan's package) for the compiler, libc, binutils, etc.
> 2) rm, cp, mv, sh, install, uname and cygwin1.dll from Cygwin. I need at
> least
> uname from Cygwin and not djgpp (DOS) because I use uname to determine the
> OS.
> 3) Perl from djgpp.
> 
> It work very well, but it looks messy to me. Any ideas.
> 
> Greetings, SET
> 
> --
> Salvador Eduardo Tropea (SET). (Electronics Engineer)
> Visit my home page: http://welcome.to/SetSoft or
> http://www.geocities.com/SiliconValley/Vista/6552/
> Alternative e-mail: set-soft@usa.net set@computer.org
>                     set@ieee.org set-soft@bigfoot.com
> Address: Curapaligue 2124, Caseros, 3 de Febrero
> Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
> 
> 
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

RE: -mno-cygwin: STATUS_STACK_OVERFLOW before main

[salvador]

fieldhouse@logica.com (Dirk Fieldhouse) wrote:


     On Tue, 01 Feb 2000 12:47:52 -0300, salvador <salvador at inti dot gov
     dot ar> wrote:

     > I have an application that compiles fine using Mingw32. When I
     > try to compile it using Cygwin B20.1 (adding -mno-cygwin and
     > -lmingw32 -lcrtdll) I get an executable, but it dies before
     > reaching main with an STATUS_STACK_OVERFLOW error.
     >
     >  I tried with --stack XXXX without luck (same crash in same
     > place).
     >...

     Check your include and link paths. Your supposed mingw32 app is
     obviously not one.

     A cygwin installation can easily get confused about a mingw32 target
     because some #define or library reference may be accidentally resolved
     against the cygwin include/library files which may follow the mingw32
     ones in the search paths. This is almost certainly the problem here.
     Is your program C++ or C - I have seen this with C++ in the past ?


C++

     There is some confusion (for me at least) about which files are usable
     in both targets - those for the Windows OS (.h and lib*.a) ought to be
     OK.

     I guess the appropriate resolution of this is for the -mno-cygwin
     specs to select a different set of paths and use -nostdinc (and the ld
     equivalent) or similar to avoid picking up cygwin stuff from
     well-known locations like /usr/include - or to be sure that you don't
     put cygwin stuff in any of these places.

I tried renaming all the lib and include directories from Cygwin (just left
lib/gcc...) and adding the -I and -L settings to pick the Mingw32 stuff from
separated directories without luck. I used -H to be sure I was picking the right
headers.
Perhaps I still doing some thing wrong.

Now I'll explain what I want to do so perhaps somebody can give me an idea:

I'm currently maintinaing a port of Turbo Vision to gcc. I have the DOS and
Linux targets working very well (they have all the needed GNU tools). Now a user
contributed a Win32 part, it compiles with Mingw32 (you just need the Mumit Khan
big file installed with gcc/binutils/run-time). It also compiles with MSVC, but
I don't have much interest in this detail ;-). Now I want to integrate the Win32
target to the configuration process, it uses common GNU tools (rm, cp, mv,
install, uname, sh, etc.) and Perl. None of this goodies are in the Mingw32
distribution so I taked a look to Cygwin, it only lacks Perl (which is a huge
drawback from my point of view, download the huge ActivePerl separatle isn't
quite nice). So I tried to compile with Cygwin and quickly found it is POSIX and
lacks a lot of things used by the Mingw32 target, I can add a Cygwin version,
after all the code compiles for Linux, but I don't have the time. Then looking
in the directories and specs files I found the -mno-cygwin trick. So I tried it,
but even when all compiles and links fine the exe dies.
So currently I have a setup that works, but is quite messy, the user needs:

1) Mingw32 (Khan's package) for the compiler, libc, binutils, etc.
2) rm, cp, mv, sh, install, uname and cygwin1.dll from Cygwin. I need at least
uname from Cygwin and not djgpp (DOS) because I use uname to determine the OS.
3) Perl from djgpp.

It work very well, but it looks messy to me. Any ideas.

Greetings, SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft@usa.net set@computer.org
                    set@ieee.org set-soft@bigfoot.com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013




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

RE: -mno-cygwin: STATUS_STACK_OVERFLOW before main

[Dirk Fieldhouse]

On Tue, 01 Feb 2000 12:47:52 -0300, salvador <salvador at inti dot gov dot ar> wrote:

> I have an application that compiles fine using Mingw32. When I 
> try to compile it using Cygwin B20.1 (adding -mno-cygwin and
> -lmingw32 -lcrtdll) I get an executable, but it dies before 
> reaching main with an STATUS_STACK_OVERFLOW error.
>
>  I tried with --stack XXXX without luck (same crash in same 
> place).
>...

Check your include and link paths. Your supposed mingw32 app is obviously not one.

A cygwin installation can easily get confused about a mingw32 target because some #define or library reference may be accidentally resolved against the cygwin include/library files which may follow the mingw32 ones in the search paths. This is almost certainly the problem here. Is your program C++ or C - I have seen this with C++ in the past ?

There is some confusion (for me at least) about which files are usable in both targets - those for the Windows OS (.h and lib*.a) ought to be OK.

I guess the appropriate resolution of this is for the -mno-cygwin specs to select a different set of paths and use -nostdinc (and the ld equivalent) or similar to avoid picking up cygwin stuff from well-known locations like /usr/include - or to be sure that you don't put cygwin stuff in any of these places.

-- 
Dirk Fieldhouse                 Logica UK Limited
fieldhouse@logica.com           75 Hampstead Road
c=gb;a=attmail;p=logica;        London NW1 2PL
o=LOGICA;ou1=UK;s=fieldhouse    UK
+44 (20) 7637 9111
- not speaking for Logica

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