Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: What real non-UNIX 'C' compilers implement...
Message-ID: <30670@sun.uucp>
Date: Mon, 12-Oct-87 14:43:19 EDT
Article-I.D.: sun.30670
Posted: Mon Oct 12 14:43:19 1987
Date-Received: Tue, 13-Oct-87 06:32:14 EDT
References: <672@sugar.UUCP> <2550029@hpisod2.HP.COM>
Sender: news@sun.uucp
Lines: 27

> A distinction that WOULD be useful is the following:
> 
>     OS: routines that are part of the kernel; your executable file
> 	does not contain them.
> 
>     LIB: routines that are linked into your executable file.

By this definition, the OS section would be pretty empty indeed....  "read"
*is*, in almost all UNIX implementations, a routine linked into your executable
file.  It just happens, in most cases, to be a trivial routine that does a
trap.

> This distinction would be useful for migrating exectuables between
> systems that had a common instruction set, system call mechanism, and
> object file format.  An example of this situation would be a system
> that ran executables linked elsewhere, but did not itself provide a
> linker or libraries.

How does this distinction help here?  Once you've built the image, if all
the routines are linked into the executable image it shouldn't matter which
routines are just system call wrappers and which aren't.  If you have a shared
library mechanism, and the routines aren't all linked in, the distinction
blurs; you now have to be sure that the library interface for the routines in
question is common across those systems.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com