Return to BSD News archive
Xref: sserve comp.os.linux:9859 comp.unix.bsd:4949
Newsgroups: comp.os.linux,comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Shared libraries - info for 386BSD porting wanted
Message-ID: <1992Sep11.214711.1389@fcom.cc.utah.edu>
Keywords: shared 386bsd
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <peter.716225737@hilly>
Date: Fri, 11 Sep 92 21:47:11 GMT
Lines: 63
In article <peter.716225737@hilly> peter@micromuse.co.uk (Peter Galbavy) writes:
>Hi,
>
>Due to no response in the bsd group a couple of weeks ago, and the fact
>I recently noticed that linux seems to have shared libraries I was
>wondering if whoever knows *lots* about them can either (a) try to port
>them or (b) help me port the implementaion across.
>
>I realise that this will not be a trivial operation, but it is a starting
>point.
>
>At minimum, will someone tell me the "minimum working set" of linux source
>files needed to understand how they are implemented. I take it there are
>bits in exec() somewhere ? and the linker etc...
You don't want to "port" the Linux code. Linux is copylefted in
a way contrary to the distribution policy for 386bsd, and the pieces we
need are going to require the same amount of work with or without it.
Do this:
o Get gcc 2.2.2 working (can generate bad 386 code currently
if optimization or debugging is on).
o Make sure you can generate position independant code (PIC).
o Fix gas so that it can assemble the PIC output from 2.2.2
(currently, it can not).
o Patch the crt.o to look for LDPATH in the environment and
to call an initialization routine (you will need a default
path set). You may also need per-library initialization
calles, so finding symbols which match an expression and
calling them may be required.
Once this is done, shared libraries require *trivial* kernel work and
dynamic stubbing.
If you want to get fancy, we can make generation of shared library stub
and initilization linkables be automatically handled as part of making
the shared library. This would probably be preferable, if one wanted to
support copy-on-write for global data symbol definitions in a shared
library, rather than simply lumping in non-sharable (writable) data in
with every program as part of the stubs (ie: initial process load would be
faster after one library using process has loaded). Depends on how much
linker work you were willing to do.
The big problem is PIC and gcc bugs. The kernel side of things is trivial
and doesn't require redistribution encumberances imported from Linux for
us to figure out how to do it.
Terry Lambert
terry_lambert@gateway.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------