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


------------------------------------------------------------------------------