Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcsun!ukc!stl!robobar!ronald
From: ronald@robobar.co.uk (Ronald S H Khoo)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Xenix files..
Message-ID: <1991Jan1.234509.3207@robobar.co.uk>
Date: 1 Jan 91 23:45:09 GMT
References: <1990Dec30.182850.15820@kithrup.COM> <1990Dec31.005602.7520@robobar.co.uk> <1990Dec31.184413.16309@bbt.se>
Organization: Robobar Ltd., Perivale, Middx., ENGLAND.
Lines: 58

pgd@bbt.se writes:

> And don't you get /shlib/libc_s with the base system?

You do.

> You only need a x.out to coff converter,
> to use it. 

I don't see what you mean...

	1) you don't get /lib/libc_s.a, (can you regenerate that from
	   /shlib/libc_s ? I have no idea how COFF shared libraries work)

	2) Xenix /bin/ld doesn't understand COFF anyway.

So how do you go about using it ?  If there is a way, more detail please!

> I have not checked, but don't you need the c-compiler to compiler c.c
> in the link kit?

No, there's no equivalent of idcomp.  The Xenix kernel configuration tables
are in *assembler* (config can generate either assembler *or* C -- using
C is better because stuff goes into BSS in C but DATA with assembler don't
ask me why) and the limited assembler provided (/usr/lib/storel I think)
is invoked to assemble them by the /usr/sys/conf/configure program.

I have no idea what the limitations of storel are, I have never used it
for anything other than configuring kernels :-)

So you are stuck with having to get gcc, but it's worth it anyway.

> I used to use gcc with the gnu loader, and my system call library,
> before the gnu OMF kit was out.

Really ?   What executable file format did you use, and what conversion
program did you use to generate it ?

> Try using GDB
> for something big, and you will get the surprise.

Big programs are the work of the devil -- all programs should fit in
64k + 64k :-) :-) :-)

Seriously though, this does mean that perhaps the way forward is to
go back to using your original technique of using GNU ld, and convert the
OMF libraries to a.out ones ?  Maybe we really ought to make the effort
to put together a complete libc.a so we can completely forget the SCO stuff.

> (On the first operating system i encountered, all system calls were
> undocumented :-( ).

Actually, I'd say that's true on Xenix as well.  Can you think of anything
more stupid than the SCO manual sections ?  *everything* is in "S" section
so no one knows what's a system call and what's not.  At least in SCO Unix
you can find out from /usr/include/sys.s
-- 
ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)