Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!kgw2!dennisg
From: dennisg@kgw2.bwi.WEC.COM (Dennis Glatting)
Newsgroups: comp.sys.next
Subject: Re: NeXT C++ under 2.0
Message-ID: <1892@kgw2.bwi.WEC.COM>
Date: 19 Jan 91 14:39:17 GMT
References: <1991Jan17.033931.4553@julius.cs.uiuc.edu> <1890@kgw2.bwi.WEC.COM> <1891@kgw2.bwi.WEC.COM> <1991Jan18.105634.1@capd.jhuapl.edu>
Sender: dennisg@kgw2.bwi.WEC.COM
Reply-To: dennisg@Xetron.COM
Distribution: comp
Organization: Xetron Corporation, Cincinnati Ohio
Lines: 28


In article <1991Jan18.105634.1@capd.jhuapl.edu>, waltrip@capd.jhuapl.edu writes:
|> In article <1891@kgw2.bwi.WEC.COM>, dennisg@kgw2.bwi.WEC.COM (Dennis Glatting)
|>  writes:
|> 	[...material deleted...]
|> > Objective-C/C/C++ mix/mash works great.  the ld problem is well documented
|> > and there is a (trivial) work around.
|> > 
|> 	I'd sure be interested in where the ld problem is documented and what
|> 	workaround is.  Bet others would be, too :^)
|> 

the problem isn't /bin/ld, it happens when /bin/ld invokes /lib/collect under csh.

somehow the csh stacksize is hardwired.   
the fix is to put "limit stacksize 10000" in your .cshrc.
this will work in _most_ cases. 

it is claimed that NeXT make has this value hardwired.   it will be
fixed in a later release.  the work around may _not_ work for those of you
using NeXT make under 2.0.  Since I use GNUmake 3.59 whatever the problem is doesn't
exist.


--
 ..!uunet!kgw2!dennisg  | Dennis P. Glatting
 dennisg@Xetron.COM     | X2NeXT developer
                        | And now a NeXT/C++ wienie