Date: Wed, 14 Feb 2001 00:47:59 +0000 From: Paul Richards <paul@originative.co.uk> To: freebsd-current@FreeBSD.ORG Subject: Re: Patch for FILE problems (was Re: -CURRENT is bad for me...) Message-ID: <3A89D5BF.D46B8FCC@originative.co.uk> References: <200102130120.f1D1KpU56194@mobile.wemm.org> <200102130131.f1D1VrW33790@harmony.village.org> <xzplmrbmk94.fsf@flood.ping.uio.no> <3A895FA0.25EBC727@originative.co.uk> <20010213131802.B79651@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote: > > On Tue, Feb 13, 2001 at 04:24:00PM +0000, Paul RichardsF wrote: > > 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, > > How is that??? Because applications expect a stable interface. If an application is developed and tested against a particular behaviour of a library function and that function's behaviour is changed it could and sometimes does break the application. More often than not that sort of failure is a side effect of *fixing* something that was previously broken. > It is beter under ELF than a.out in that ld.so isn't making a guess as > to which shared libs were compatible and which weren't. The ELF ld.so > does not look for shared lib libxyz.so.2, find libxyz.so.3 and decide > maybe they are close enough and use it instead. The a.out ld.so would > use libxyz.so.2.2 when the binary was compiled and tested with > libxyz.so.2.1. Instead what we have now is libxyz.so.3 and libxyz.so.3 which are different from each other. When you've got an application that just broken you've got no way of finding out which version of the library was the working one, or any way of linking against it because it cannot co-exist with the newer version because they've got the same name. This is precisely the problem we've got now. Maybe I didn't make it clear in my last email, it's not the old a.out way of picking the library to link with that was better, it was the finer grained versioning. > > > we're suffering a worst case scenario of this problem > > now but even "fixes" in new versions can cause applications to break and > > Don't confuse development (which in years past would have never made it > out of the "company's" development machines, with deployed releases. This applies to released code as much as in-development code. When you login to a strange machine and you're trying to diagnose a problem there's no way to know whether the libc they've got installed is of version X or version Y because there's nothing to tell you what sources libc.so.Z was built from, it could be the .Z version with the X fixes or the Y fixes. To be honest, DLLs are better than our scheme from that perspective. While you might screw a load of applications by upgrading a DLL with the same name you can at least look at the version number in the properties to find out which version of that DLL it is. There's no way of looking at a libc.so.5 and say which version of libc.so.5 it is. Although `ident` does provide a slightly cumbersome way of getting some information to help with that when you really need it. > > we've already seen this many times in this iteration of -current. > > *Way*, way too many people are using -CURRENT that have no business doing > so. I agree with that, I've always been an advocate of raising the barrier of entry to using -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. > > We have that today and it works very well [in our released product]. > > 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. > > NO! Please review the rules ld.so in both ELF and a.out varieties uses > in finding a desired shared lib. You've missed the point I was trying to make. Our reluctance to bump what we perceive to be a major number is hampering our ability to differentiate between different versions. It has nothing to do with the difference between a.out and Elf library selection, it's a project policy problem. We could just as easily use a minor numbering scheme with Elf to indicate that a version change has occured but not an interface change. To some extent a three figure version number does something along those lines. If we bumped the version number with a bit more abandon this problem wouldn't even be a problem. Paul. 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?3A89D5BF.D46B8FCC>