In quest of a decent editor

[Marty Connor]

In article <2815 at crash.cts.com>, cline at pnet01.cts.com (Ben Humphreys) writes:
> In quest of a decent editor...
>   Warning: xx different levels of indirection
> in a few source files.

This is probably ok.  A little caste might make it go away, but
shouldn't hurt anything.

> cc's call to ld (I think) produced the message:
>   DGROUP > 64k

This means you had more than 64K in your 'small-model' data segment I
think.  I believe you have to compile uEmacs 3.9 as a large model program.

> Well, not knowing the development system all that well, I thought adding
> the switch -LARGE might help.  It didn't as I recall.  

This lets you compile like large source files, but unless you use the
flags  '-Ml2e' you will not get a large model program, and it will
still not link.

Then I remembered
> someone suggested the switch -Ml2t128 for monster programs worked well.  I
> added that and got a new message from the linker after recompiling all the
> source files:

Close, very close.  The '-Ml' says large model.  The '2' says make 286
instructions.  The 't128' says put anything larger than 128 bytes in
its own segment.  probably not a good idea for this program.

>   Fixup overflow near 008b in segment PREPROC_TEXT in \
>   /lib/Llibc.a(signal.o) offset 262d8H

Yeah, I would just say "-Ml2e" or "-Mle"  (the 'e' says enable
keywords 'far' and 'near').

> Has anyone been successful in producing an executable Micro EMACS under SCO
> XENIX 2.1.3?  I sure haven't.

I did once do this.  I think you should be able to also.  If you get
'infinite spill' errors, you should find the lines that give them and
change code of the form:

   foo->bar[i++];
to
   foo->bar[i]; i++;

the compiler gets confused sometimes.

Bon Chance.

I think if you can afford it you should upgrade
to 2.2.1 or 2.2.2.  I used 286s and switched to a 386 and got away
from a lot of this memory model madness.  The x86 architecture still
is pretty brain dead in some ways though.

----------------

While I have you all here, had anybody gotten KCL to work on SCO XENIX 386
V 2.2.1?  It seems to take great offense at the memory management of
SCO.  We want to modify code in the text section, and apparently it is
not allowed.  All ideas thankfully received.

-- 
----------------
Marty Connor
Director of Innovation, The Entity
mdc at mcp.entity.com, ...{harvard|uunet}!mit-eddie!spt!mcp!mdc