Subject: Re: bin/396: ld/ld.so (on hp300) pay too much attention to shared library minor numbers
To: None <downsj@CSOS.ORST.EDU>
From: J.T. Conklin <jconklin@netcom.com>
List: netbsd-bugs
Date: 08/06/1994 16:52:34
> Recently, I had occasion to increment my libc's minor number, and
> then revert back to 12.0. Upon doing so, those binaries that were linked
> during the existance of libc.12.1 no longer worked, as ld.so would
> fail. This is wrong, since ld.so shouldn't care what the _minor_ number
> was at original link time, only the _major_ number. It should simply
> pull in the highest numbered _minor_ revision that exists at run time.
I don't know about this. Aren't minor numbers supposed to be updated
when *new* interfaces are added to a library. For example, I'll be
adding float versions of most of the math functions to libm soon -- I was
planning to update the minor number from 0 to 1. Programs linked against
0.0 will still work with 0.1, but those programs that use sinf() or any of
the other float math functions won't work with 0.0.
I hope this is the case. On a slightly related subject, I'd really like a
method to control (or at least contain) the major number explosion.
Wouldn't it be great if netbsd 1.1 could go out the door with a C library
with major number 13 instead of 26?
--jtc
------------------------------------------------------------------------------