🚀 go-pugleaf

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