Date: Tue, 13 Feb 2001 16:24:00 +0000 From: Paul RichardsF <paul@originative.co.uk> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Warner Losh <imp@harmony.village.org>, Peter Wemm <peter@netplex.com.au>, Daniel Eischen <eischen@vigrid.com>, John Indra <john@office.naver.co.id>, freebsd-current@FreeBSD.ORG Subject: Re: Patch for FILE problems (was Re: -CURRENT is bad for me...) Message-ID: <3A895FA0.25EBC727@originative.co.uk> References: <200102130120.f1D1KpU56194@mobile.wemm.org> <200102130131.f1D1VrW33790@harmony.village.org> <xzplmrbmk94.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote: > > Warner Losh <imp@harmony.village.org> writes: > > I've had problems in the past going backwards on major versions of > > shared libaries. The major problem is that if I have binaries that > > refer to libc.so.503, then when the major number is reverted back to > > 5, it is a nop because ld will use libc.so.503 for new binaries. > > When we back down to 5, we add magic to the Makefiles to move > libc.so.5?? to /usr/lib/compat - that way they're only used when > needed at runtime, not for linking new programs. > > > What's wrong with shipping with say libc.so.505 in 5.0 and then say > > libc.so.645 in 6.0? > > Umm, I dunno, except that it'll look weird, but that's just a matter > of taste. I actually quite like this idea, I prefer it to the dropping down to a single digit. What happens if there's a critical fix in a -stable branch, we *must* have the option to bump library versions when we need to and if we release 5-stable and intend to release 6-stable with libc.so.6 then you've got problems if you find a showstopper in 5-stable and need to release a new libc in that branch. If we have 3 digit library versions then there's always scope to roll forward library versions on a branch, as long as there aren't more than 99 of them :-) > Of course, what we really need is "mandatory minor numbers", i.e. > minor numbers that are treated as "I need this version", not as "I > need this version or newer"... *ducks* *runs* When we dropped minor numbers I had a worry that we'd run into one of Windows' greatest problems and we have. Applications that are developed and tested to work with a particular library might not work with a different version, we're suffering a worst case scenario of this problem now but even "fixes" in new versions can cause applications to break and we've already seen this many times in this iteration of -current. I think we need some form of version control on libraries so that applications know whether they're linking with the version they're designed for and to be able to keep multiple versions around in the system so all applications continue to work. I understand the reasoning that Elf doesn't need minor numbers but they served an useful purpose in maintaining application compatibility that we now lack. If there isn't any better solution then we should be much more free and easy in bumping the version number because otherwise we're storing up problems exactly along the lines that makes Windows so flakey when you change a dll. Another issue is that if two versions of a library have the same number then there's no way to find out which the application was intended to link against. If the version number is bumped more regularly then you can scan the filesystem and ldd the binaries to find out whether they need to be rebuilt against a new library. Given a lot of negatives and only an asthetic postive library bumping should take place much more often and moving to a 3 digit number based on the branch actually makes a lot of sense. Paul Richards To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A895FA0.25EBC727>