Xenix files..

[Sean Eric Fagan]

In article <1991Jan2.200940.3320 at bbt.se> pgd at bbt.se writes:
>I did not even know I was missing /lib/libc_s.a, or what it contains...

It contains the stubs for the shared library.

I am going to try to summarize what I think you've been trying to do, and
then I'm going to tell you why you cannot.  If I've misunderstood you,
please let me know, and I will tell you why you're wrong with the new
understanding.

You are trying to generate programs that use shared libraries, using only
the standard Xenix 2.3.0 devsys.  You have noticed that the shared libraries
are in /shlib/libc_s, and that an nm of them shows some symbols, which you
assume you can jump to.

Correct?

This is *not* correct.  There are two parts to a shared library:  the shared
part (obviously 8-)), and the non-shared part.  The private part, which is
mostly contained in libc_s.a (the archive you get with -lc_s) does a few
things, such as actually jumping to the correct entry in the jump table.
The shared part is, for all intents and purposes, an executable, with
references to data and jump tables that are not resolved therein.  The jump
table of the shared library is rigidly defined:  changing it will break any
application that uses that part of the library, unless you recompile it.
(You can, however, add to the shared library, if you have the definition
file, which is not shipped with either xenix or unix.)

>I have a printf("hello") program, and the only missing routines, from the link,
>are Scrt0, start, exit, and cleanup. The problem is start, which has
>to make special initialization for the shared library. This means that
>libc_s is giving the core of libc.a

Huh?  That doesn't parse too well.

The shared library has unresolved references to malloc and free, among
others.  This is so that you can link in your own version of malloc, and all
of the routines in the shared library will use it.  Please tell me how you
managed to resolve these?  They won't show up unresolved, because there is
no symbol name in the shared library for them; instead, there is a table,
which is filled in by the linker, *IF YOU HAVE THE SHARED LIBRARY ARCHIVE*.

>To get the xenix kernel to load the library, I use a program which
>converts the executable x.out file, to an executable coff file, and
>puts in the information to load the library in it. That part works
>nicely. 

*No*.  That part only *appears* to work nicely.  In reality, it is doing
something very strange, and bizarre, and not terribly useful.

>Most x.out utilities on xenix, actually work with coff format. ld
>accepts coff format as input.

And generates x.out stuff.  It calls a cvtcoff program, I believe, which
converts the COFF to OMF, and then links.

Although it is possible to reverse engineer the stuff necessary for a shared
library, it does not sound as if you have done it.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef at kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.