Subject: Re: NetBSD 2.0 release date
To: Jason Thorpe <thorpej@wasabisystems.com>
From: John Franklin <franklin@elfie.org>
List: tech-kern
Date: 12/08/2003 13:02:20
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:
>>> Version checks will not solve the problem. Sigh, I guess I'll have=20=
>>> to repeat the crux of the problem *again*.
>>>
>>> Consider this:
>>>
>>> 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=20=
>>> checking, you still lose in this situation. What if foo and=20
>>> libother both call function zap(), and zap() is one of the things=20
>>> that had an ABI change between the two libc versions?
>>
>> How would this program even link? Wouldn't the linker return a storm=20=
>> of duplicate symbols as it tries to resolve through both versions of=20=
>> libc?
>
> What if program foo was compiled on a different host, and you received=20=
> it as a binary? What if, on that other hose, libother.0 had a=20
> recorded dependency on libc.13 (i.e. it is a "fresh install"), but you=20=
> are running it on a host that has an older libother.0 that has the=20
> libc.12 dependency.
On the other host, foo is linked with libc.13 and libother.0=20
dependencies. Locally, the loader would try to load both libc.13 (to=20
satisfy the foo dependency) and libc.12 (to satisfy the libother.0=20
dependency.) Conflicting library versions, program doesn't load, error=20=
is returned. It's OK for the loader to say no.
Alternately, the loader could resolve the symbols so the libother.0=20
text segment uses libc.12 and the foo text segment uses libc.13, but=20
that would create a bigger mess. Debugging program failures would be a=20=
nightmare.
> This is a totally normal, acceptable situation that should work=20
> (assuming the library minor numbers are the same).
If foo *doesn't* depend on libc, then locally the loader will load=20
libother.0 (for foo) and libc.12 (for libother.0, local edition.) Only=20=
one libc major, life is good. (I know, it isn't likely a program won't=20=
depend on libc.)
This can be done if the linker is smart enough to include dependencies=20=
only for what libraries the program's (or library's) text segment=20
directly references, and the loader fails when it gets multiple,=20
different lib majors.
jf
--=20
John Franklin
franklin@elfie.org
ICBM: 35=B043'56"N 78=B053'27"W