Two comments here:

1) Seems to me a better architecture would be client/server.  The ap requests
the library from a "library server" - this would return the absolute path
name of the library.  Something like library_server(lib_name, lib_version);
How it finds it can be hidden in an abstraction.  (I think that it's a bit of
a hack to include the version in the library's filename.)

The abstraction could be extended to return the actual library bits & load
it, whether the library was local or remote (over the network).

2) "DLL Hell" must be avoided; in the Windows world, conflicting or "upgrade"
DLLs sometimes render older apps inoperative, since the newer DLLs sometimes
aren't bug-for-bug compatible.

I think the only general solution for this is to use the exact library with
a given ap.  Perhaps some kind of "SCCS" for library files could be used,
so that a binary diff could be applied to a current library file to make
available previous versions.

-Mike


On Tue, 17 Aug 1999, Robert Elz wrote:

>     Date:        Mon, 16 Aug 1999 01:50:27 -0400
>     From:        Ken Hornstein <kenh@cmf.nrl.navy.mil>
>     Message-ID:  <199908160550.BAA20271@ginger.cmf.nrl.navy.mil>
> 
>   | I have to agree with everything Brian has said.  I think that we're sorta
>   | going backwards here without _some_ way of configuring library search
>   | paths.
> 
> But of course, it is a religious argument, with people believing that
> ldconfig is necessarily evil, they don't need it, and hence, no-one should
> be given it.  It is essentially impossible to win an argument against that
> kind of opposition, so it is probably best to just not bother.
> 
>   | HP/UX has a tool for changing the rpath of an already-linked executable.
>   | It seems to me that this would be nearly ideal.
> 
> It would be quite useful, for the cases where you get an isolated binary
> or two, that were compiled with different assumptions.
> 
> But where the issue is that you want to move a whole bunch of libraries
> from one place to another (say you want to turn use of xpkgwedge on or
> off - but not recompile the whole universe) racing around attempting to
> first find, and then edit, all of the affected binaries, while possible,
> can't really be called "ideal".   Nor is leaving large numbers of symlinks
> around.
> 
> kre
> 
> ps: just in case the first paragraph (of mine) above wasn't sufficiently
> clear - I believe that not having a system wide way to set library search
> path defaults is ludicrous - and just as stupid as the SysV way of handling
> TZ (where eevry application has to have it set, from somewhere, to be able
> to discover the local timezone).
> 
>