Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!alphalpha.com!nazgul
From: nazgul@alphalpha.com (Kee Hinckley)
Newsgroups: comp.windows.x.motif
Subject: Re: libXt.a is it motif or is it X?
Message-ID: <901210214907.7237@alphalpha>
Date: 11 Dec 90 02:49:07 GMT
References: <9012102355.AA18519@thyme.jpl.nasa.gov>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 19

> Why should the presence of Vendor.o in two libraries make any difference?

The Sun model of shared libraries is that they are just like linked libraries,
except that you get them at runtime.  The Apollo model is that the library
may or may not be around at linktime, all you are doing is promising that
*something* will be around at runtime to resolve the symbol.  The something
might be globally loaded when the machine boots, loaded the first time
a program trys to reference it, loaded explicitly from a file specified
at link time, or preloaded by the user in the context of the current shell
(I can just say "inlib foo" and promptly get a whole new library context
for any program I run subsequently)  The "load explictly from a file specified
at link time" is closest to the Sun model, and I can get by with two versions of the
routines in Vendor.o in that case.  However if I want to use load on reference it
clearly won't work, since the reference is ambiguous.  Additionally I'm
working in an environment where everything else is R3, so it's easiest if
I bind Xm, Xt and even X11 into a single shared library; and I can't have
duplicate references there either.  Thus the question.

				-kee