Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!seismo!rochester!bullwinkle!uw-beaver!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: net.micro.pc
Subject: Re: Xenix S5 286 Stack Problem
Message-ID: <316@omen.UUCP>
Date: Tue, 25-Mar-86 21:36:48 EST
Article-I.D.: omen.316
Posted: Tue Mar 25 21:36:48 1986
Date-Received: Fri, 28-Mar-86 07:47:18 EST
References: <948@rlgvax.UUCP> <177@transys.UUCP>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology, Portland
Lines: 21

In article <177@transys.UUCP> baron@transys.UUCP (Joe Portman) writes:
>In <948@rlgvax.UUCP> Dennis Bednar writes:
>
>> It does not seem possible to tell the Xenix SV compiler/loader for
>> the IBM PC/AT (286 CPU)to build an a.out with a large enough stack
>> segment in some cases.
>I have run across this exact problem, notably with compiling and setting up
>the usenet software.
>
>I solved it by:
>
>1.	using the -M2l and -s -i flags of the compiler. This sets the compiler 
>	to LARGE memory model and enables 286 code generation. It also allows
>	multiple data segments. The -s strips the symbol table and the
>	-i says SEPARATE instruction and data space. This is implied in
>	middle, large and huge models, but MUST be specified in the default
>	model (small).
That implies you have a C compiler with a working large model.  I have yet
to see a Xenix large model that can compile the average non trivial program
without an extreme amount of hacking to avoid compiler bugs.  I eagerly
await such a Xenix compiler, but am not holding my breath.