Subject: Re: ld.so.conf?
To: Robert Elz <kre@munnari.OZ.AU>
From: Mike Cheponis <mac@Wireless.Com>
Date: 08/16/1999 10:48:15
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.
On Tue, 17 Aug 1999, Robert Elz wrote:
> Date: Mon, 16 Aug 1999 01:50:27 -0400
> From: Ken Hornstein <email@example.com>
> 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
> 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).