Date: Mon, 27 Mar 1995 15:09:51 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: Poul-Henning Kamp <phk@ref.tfs.com> Cc: current@FreeBSD.org Subject: Re: shared library versioning Message-ID: <199503272209.PAA03636@trout.sri.MT.net> In-Reply-To: Poul-Henning Kamp <phk@ref.tfs.com> "Re: shared library versioning" (Mar 27, 1:52pm)
next in thread | previous in thread | raw e-mail | index | archive | help
[ adding strhash() functions to libc and shared lib bumping ] > > If folks want to run 2.1 binaries on their 2.1 machines, then they need > > the 2.1 libraries as well. They go hand in hand. (Assuming the ld > > changes don't bite them). If they want, they can delete the 2.0 > > libraries as so far all of them are un-necessary and can be replaced by > > the 2.1 versions. > > > > You can't have it both ways. > > No I can't. But until somebody actually uses that particular symbol for > something, then I don't really want to see 2.1 being >that< incompatible. If that symbol is not needed, then it can be removed from the library and the shared library doesn't need to be bumped. But, I assumed they were added because they were going to be used, so there are going to be program(s) using them. I guess I assumed it would be silly for Jordan to add something to libc that he wasn't planning on using. And, it's not that incompatible. That why shared libraries are the way they are. Everything is 'updwards' compatible, but nothing is guaranteed to be downwards compatible. > Alternatively we shoule decide that this is the way it will be, and bump > the number at any and all release hereafter. Why? If the libraries don't change, then why bump the number? The point of shared number versions is to allow you to change the number IFF it needs to change, and not when it doesn't need to. The numbering scheme goes as follows.: 1) Major numbers == same interface and calling convention. If you modify a function's parameters & type, then the major # needs to be bumped. There is no way a program who thinks msync() needs 3 parameters is going to work against a library that uses 2. We've ignored that change in FreeBSD since according to David and Ache, msync() never worked anyway so a program using it was broken before the interface changed. 2) Minor #'S. If the same routines exist as have always existed, but we are adding new functionality then bump the minor # so we can differentiate between a shlib containing ONLY the old routines and a shlib containing the OLD + NEW routines. Else, we will get run-time errors when new programs which expect the new routines are run in system which contain only the old shlib. Your response to bump the minor # only when programs are added to the system is irrelevant which use the new functionality because of the implicit assumption that the functionality was added because it was going to be used. Therefore, we must bump the minor # when the library changes since that is what changed, not the programs. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503272209.PAA03636>