Date: Tue, 28 Mar 1995 21:02:24 +1000 From: Bruce Evans <bde@zeta.org.au> To: jkh@freefall.cdrom.com, phk@ref.tfs.com Cc: bde@zeta.org.au, current@FreeBSD.org, davidg@Root.COM, paul@isl.cf.ac.uk, wollman@halloran-eldar.lcs.mit.edu Subject: Re: shared library versioning Message-ID: <199503281102.VAA20354@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > I didn't see a bump, but as a result of this change, it should be. >> >> So instead of said binaries failing catastrophically on a link >> error, they just fail to find the library in question and fail >> catastrophically on a missing library? >> >> I somehow fail to see the point. >So do I. The point is that it fails cleaner if the library is missing. I just tested this. I removed strhash.o from libc.so and tried running a version of dmenu that was linked while strhash.o was in libc. dmenu runs OK in the empty directory /tmp. but in the dmenu directory it runs long enough to mess up the tty mode and then exits when it tries to call an nonexistent function. >This will make >ALL< 2.1 binaries fail on a 2.0 system, leaving the >version number as it was would only have a few 2.1 binaries (as of yet >nonexistent ones) fail on a 2.0 system. The ones that call the libraries that I listed in previous mail (mostly curses-based apps) have to fail, but there's no need to have the ones that are only linked to libc fail. >revert please. I agree. Put strhash.o in libjkh or somewhere. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503281102.VAA20354>