Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!hp-pcd!hpcvc0!hpcvcd!charles
From: charles@hpcvcd.HP (Charles Brown)
Newsgroups: comp.sys.amiga
Subject: Re: A shared library (mostly) in C
Message-ID: <4410007@hpcvcd.HP>
Date: Sat, 13-Jun-87 23:53:33 EDT
Article-I.D.: hpcvcd.4410007
Posted: Sat Jun 13 23:53:33 1987
Date-Received: Sat, 20-Jun-87 21:05:33 EDT
References: <10090@decwrl.DEC.COM>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 29

>>If I have (say) an "iff.library" that has an IFF read routine called
>>"iffread" and you have a library for your application called "myapp.library"
>>that also has a routine called "iffread", which one gets used ...

>...	 the linker will resolve it with the first match
>it comes across.  So you decide which of two conflicting-name functions
>you get by simply specifying the proper .lib order in your link.

This sounds like an excellent start.  However, there are still some
irksome limitations.

Consider the case where my.library and your.library both have
definitions for foo and bar.  If I want to use foo from my.library
and bar from your.library I have a problem.  This problem is similar
to executing commands from a shell or CLI.  The PATH defines the
order in which directorys are searched.  But I can still specify a
full path name if I want to override that choice.  If this is applied
to librarys, it gives the programmer the power to protect his program
from changes in the users run time environment.

Notice that the same concept can be applied to compile-time-linking
as well as run-time-linking.  In the case of compile time linking, it
is mostly a convenience for the programmer.  Of course, if I want to
link BOTH versions of foo, the problem is worse.  If properly thought
out, I am sure even this pathological case could be handled with full
path name linking.

	Charles Brown		hplabs!hp-pcd!charles
	"Just a thought"