sitze@nmsu.edu (Richard Sitze) (05/29/90)
I'm getting
LINK : error L2041: stack plus data exceed 64K
for a program writting in Microsoft C 5.1. The program consists of a large
number of seperate object files & libraries. The object files have all
been compiled with the following flags:
/Zl /W3 /Oailsp /AL /J # optimizations, large model
I've also tried (for the object files but not the libraries):
/Zl /W3 /Oailsp /AL /Aw /J
in an attempt to locate the stack segment by itself. I'm not sure I
correctly understand the purpose of the /Aw flag.. The files are all linked
with the following flags to the linker:
/NOI /F /PAC /ST:8196
So, the questions are:
1) anyway to convince the linker to create a seperate stack segment?
2) any nice easy fix to this?
3) any difficult fix to this?
4) any helpful/constructive comments of any sort?
I'm stumped, tired, frustrated, and going home. Any help would be
greatly appreciated. BTW, please ignore the 'path' and 'from'
field in the header, they are the result of a screwy system here
on campus. I'm quite able to read news, but any email should be
sent to
sitze@nmsu.edu
Thanks in advance,
<ras>
--
+--------------------------------------+
| Richard A. Sitze |
| sitze@nmsu.edu phone: 646-6228 |
+--------------------------------------+jeras@oracle.oracle.com (John Eras) (06/10/90)
In article <SITZE.90May29101947@teewi.nmsu.edu> sitze@nmsu.edu (Richard Sitze) writes: > >I'm getting > >LINK : error L2041: stack plus data exceed 64K > >for a program writting in Microsoft C 5.1. The program consists of a large >number of seperate object files & libraries. The object files have all >been compiled with the following flags: > > /Zl /W3 /Oailsp /AL /J # optimizations, large model > >I've also tried (for the object files but not the libraries): > > /Zl /W3 /Oailsp /AL /Aw /J > >in an attempt to locate the stack segment by itself. I'm not sure I >correctly understand the purpose of the /Aw flag.. The files are all linked >with the following flags to the linker: > > /NOI /F /PAC /ST:8196 I see this question fairly regularly. The fix is trivial, and does not involve moving the stack into its own segment. (You want separate stack and data segments? With msc 5.1? Ha ha ha ha ha ha ha ha ha ha!) The fix is this: o Compile with a low(er) -Gt size. This sets the threshhold for the size of objects which will be allowed into the default data segment; larger objects will be put into far data segments. This is especially important, as it leaves space in the DS/SS segment for your stack by moving data out. The default -Gt is something like 32767 or some other equally huge-mongous number. o Link with /PACKCODE (/FAR), and /PACKDATA if your linker has it, if you need to. This is just to cut down on the number of segments used, since lots of segments will invariably be used with low -Gt settings. Um, that oughtta do it. ----------------------- (: smile! you're on usenet! :) ------------------------ AT: jeras@oracle.com | "It's a terrible waste BANG: ...{pacbell,hplabs,apple,decwrl}!oracle!jeras | to lose one's .sig, or FLAME: /dev/null (nyuk, nyuk) | not to have one at all."
mac@idacrd.UUCP (Robert McGwier) (06/11/90)
From article <SITZE.90May29101947@teewi.nmsu.edu>, by sitze@nmsu.edu (Richard Sitze): > > I'm getting > > LINK : error L2041: stack plus data exceed 64K > Richard: Do you REALLY need these big variables to be local variables. I would malloc these large arrays (fmalloc if you are using a small model) thse variables off the far heap and then your stack overflow problems should goi away. You just can't get more than 64K out of a single segment, which is what you get when you set SS. USE MALLOC, THIS IS WHAT IT IS FOR! Hope this helps. Bob -- ____________________________________________________________________________ My opinions are my own no matter | Robert W. McGwier, N4HY who I work for! ;-) | CCR, AMSAT, etc. ----------------------------------------------------------------------------