Date: Thu, 01 Oct 1998 15:35:28 -0400 From: "Kaleb S. KEITHLEY" <kaleb@ics.com> To: hackers@FreeBSD.ORG Subject: Re: ELF shared library "revision" numbers Message-ID: <3613D980.3C606C15@ics.com> References: <Pine.BSI.3.95.981001104117.6970C-100000@fish.hooked.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex wrote: > > > The definition of "incompatible" that FreeBSD has chosen > > > includes adding new functions while keeping all the previous interfaces > > > unchanged. > > > > Ugh. That's bad. That's going to force people to keep old libraries > > around for old programs, and /usr/lib is going to suffer from bloat. > > Either that or it's going to force people to go manually dink their > > /usr/lib to create symlinks if they want to get rid of old libraries. > > (Yeah, yeah, disk is cheap.) > > It's _good_. Anything that results in an accretion of versions of libraries in /usr/lib is not _good_ by any stetch of the imagination. > It would force people to link statically if they're horribly desparate, I'm glad all that work was done to make shared libraries work, just so people could tell us to link statically. > or perhaps just relink. Thanks, but no thanks. Being forced to relink hundreds of programs just because I've upgraded FreeBSD from 3.0 to 3.1? That doesn't sound like user friendly to me. > Yes, it's true Linux added new > functions to its libc5 without bumping the major number. Let me tell you, > when you've got a populace that's so full of clueless idiots, doing > something like that is a bad idea. The clueless idiots don't seem to have had much of an impact on anyone else who has a sane (my definition of sane) policy for incrementing the version of a shared library. > Ever try and run programs linked with > libc.so.5.44 on a libc.so.5.12 system? It's not fun, but something like > that _should_ work. Why should it work. If a program wants the foobarbaz function in libc and it's not there, the dlsym will fail, and the program will exit. If foobarbaz gets added to libc in FreeBSD 3.7 and some shrinkwrap software needs the foobarbaz function, then it'll specify that FreeBSD 3.7 or later is required. > When you introduce binary or source incompatablity, > it's time to change the major number. Out of all the ELF systems out there you're clearly in the minority with this opinion. And for good reason I'd say. > > > Bumping the SONAME/version when you add APIs doesn't buy you anything. > > It buys you sanity. I wouldn't use the word "sanity" to describe a situation that's going to result in 57 (or even five) versions of libc in /usr/lib. Because there will be programs that just can't be relinked -- count on it. > Unless you want to explain why a libc.so.3 from the > 12th won't work with programs linked with a libc.so.3 from the 13th. You need to remember that there's a difference between "production" use of the system and what the developers are doing. Only a developer is going to have the problem you describe (and there are ways to work around that). Systems in "real" use aren't going to be changing their libc like you are. Gee, it seems like it was only yesterday (even though it was really three or four years ago) that I suggested switching to ELF. Back then I was told that switching to ELF wasn't such a good idea. History really does repeat itself. -- Kaleb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3613D980.3C606C15>