On Mon, Dec 08, 2003 at 01:02:20PM -0500, John Franklin wrote:
> On Dec 8, 2003, at 12:03 PM, Jason Thorpe wrote:
> >On Dec 8, 2003, at 8:42 AM, John Franklin wrote:
> >>On Dec 7, 2003, at 3:06 PM, Jason Thorpe wrote:
> >>>	program foo depends on libc.13 and libother.0
> >>>
> >>>	libother.0 depends on libc.12
> >>>
> >>>*EVEN IF* you have 100% complete inter-library version consistency 
> >>>checking, you still lose in this situation.  What if foo and 
> >>>libother both call function zap(), and zap() is one of the things 
> >>>that had an ABI change between the two libc versions?
> >>
> >>How would this program even link?  Wouldn't the linker return a storm 
> >>of duplicate symbols as it tries to resolve through both versions of 
> >>libc?
> >
> >What if program foo was compiled on a different host, and you received 
> >it as a binary?  What if, on that other hose, libother.0 had a 
> >recorded dependency on libc.13 (i.e. it is a "fresh install"), but you 
> >are running it on a host that has an older libother.0 that has the 
> >libc.12 dependency.
	or you just went and updated libother.0 without updating the program.
(e.g. in pkgsrc parlance: make replace)

> On the other host, foo is linked with libc.13 and libother.0 
> dependencies.  Locally, the loader would try to load both libc.13 (to 
> satisfy the foo dependency) and libc.12 (to satisfy the libother.0 
> dependency.)  Conflicting library versions, program doesn't load, error 
> is returned.  It's OK for the loader to say no.
	what would be really neat is if the ld.so would look for earlier versions
of libother.0 that has the matching dependency.  If libother.0.2 is linked
against libc.13, but libother.0.1 exists and is linked against libc.12, then
program foo, linked against libother.0 and libc.12 should be able to work
just fine using libother.0.1.  _That_ would allow full backwards compatibility
without bumping major versions.

> If foo *doesn't* depend on libc, then locally the loader will load 
> libother.0 (for foo) and libc.12 (for libother.0, local edition.)  Only 
> one libc major, life is good.  (I know, it isn't likely a program won't 
> depend on libc.)
	and not entirely trivial to create one that doesn't.  You have to run
ld by hand, omit crt0.o, write your own _start(), and probably more.

eric