Date: Fri, 10 Sep 1999 14:29:49 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <37D8F9BD.E364BDC7@scc.nl> References: <199909101123.PAA02006@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitrij Tejblum wrote: > FreeBSD 4.0 currently have a nice feature - libc compatibility with > FreeBSD 3.x. That is, I can link a program build on 3.x with the libc > build from src/lib/libc on -current, either dynamically or statically. > I also can do it in other way around. I _use_ this feature every > day. (Note: this feature is traditional. You was mostly able to do the > same with 2.2.x and 3.0 (if you stuck with aout) - the major version number > was not bumped in 3.0. You actually could do the same with 2.1 and 2.2 > - the incompatibility between libc.so.2.2 and libc.so.3.0 was mostly > imaginary, and people used to symlink libc.so.2.2 to libc.so.3.0 and > most program worked.) You can compile programs on -stable and let them run on -current. This holds for both staticly and dynamicly linked binaries. This is what backwards compatibility is all about. Compiling on -current and running on -stable can give you problems. > Now, you are going to break the feature. What do you offer in return? It's not a feature. It happens to be that way sometimes in the chain of events. > 32+ signals. I am probably not going to use the new feature. You hardly > will find a lot of people who desperately need it: most people don't care > at all, most of other would need to deal with 3.x with only 32 signals > anyway. OTOH, the compatibility feature will be more important for quite > a few people when 4.0-BETA and 4.0-RELEASE will be released. So, I don't > think it is a reasonable tradeoff. FUD. I don't see anyone else complaining. OTOH, I do receive implicit and explicit support in changing sigset_t. > Thus, I object. Please don't break the compatibility. Perhaps, restrict > it to kernel internals and the linux emulator, if you need it for linux > emulation. I now understand your point of view. It doesn't really have anything to do with whether or not we should have a version bump. Your arguments are simply rooted in your way of programming and/or compiling and the (false) assumption that you can depend on libc being interchangable across different versions of FreeBSD. > The solution I suggest, of course, will partially break the compatibility > feature anyway. But only in a relative small part. This may be a > reasonable tradeoff. I don't see how your solution can maintain a higher degree of compatibility then a version dump. In both cases you can run -stable binaries on -current but not the other way around. > [perhaps, I will answer the rest of your mail later] I do hope so. I think that adding functions to hide datatype changes have more drawbacks then version bumps, but I may be mistaken. Nonetheless, it's an important issue. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org 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?37D8F9BD.E364BDC7>