From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Linux beoming a real choice? Date: Mon, 7 Jun 1993 03:43:24 GMT
In article <C87J9K.BF7@ra.nrl.navy.mil> eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>In article <9306052002.53@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>>In article <C83rLr.3u6@jti.com> richb@jti.com (Rich Braun) writes:
>>Actually, the SVR3 iBCS (COFF) would be the best standard as that is where
>>the bulk of the shrink-wrapped commercial products go.
>
> If someone is really interested in iBCS (i.e. running $CO binaries),
>then let me know, and I can get you started hacking the kernel to get these
>running.
Actually, many SCO binaries use a shared library also. The problems here are:
(1) the 3.2.2 (at least) shared libc was fairly buggy, and (2) SVR3 shared
libraries are ridiculously difficult to create. Although if the calling
sequence can be made to work with e.g. a modified Linux shared library (I
don't think so, regrettably; the Linux "jumpas" business makes it difficult)
you might be able to do it more easily.
SVR3 shared libraries involve jump tables for functions and a standard archive
for data (including constant data). The latter solves the problems of Linux's
jump libraries but means that constant (text segment) data is not shared.
This is *not* dynamically linked; the archive (conventionally named <lib>_s.a,
e.g. libc_s.a) contains stubs which call through the jump table. This won't
be easily duplicated using Linux shared libraries because of the different
handling of data and the inability of shared libraries to link against
non-shared libraries. (And no, this wouldn't be a simple patch to the DLL
tools, as far as I can tell. It might be a complex one, though....)
++Brandon
-- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.orgIt's not too late to turn back from the "Gates" of Hell... Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?