From owner-freebsd-hackers Thu Sep 9 7:38: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 1F5E8150B4 for ; Thu, 9 Sep 1999 07:37:56 -0700 (PDT) (envelope-from tejblum@arc.hq.cti.ru) Received: from arc.hq.cti.ru (localhost [127.0.0.1]) by arc.hq.cti.ru (8.9.3/8.9.3) with ESMTP id SAA04752; Thu, 9 Sep 1999 18:36:54 +0400 (MSD) (envelope-from tejblum@arc.hq.cti.ru) Message-Id: <199909091436.SAA04752@arc.hq.cti.ru> X-Mailer: exmh version 2.0zeta 7/24/97 To: Marcel Moolenaar Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions In-reply-to: Your message of "Thu, 09 Sep 1999 14:59:37 +0200." <37D7AF39.ECC65D14@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Sep 1999 18:36:52 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dmitrij Tejblum wrote: > > > > Marcel Moolenaar wrote: > > > > I suggest to try to avoid the version bump. NetBSD-like way to do it: > > > > Give new implementations another names in object files, so that they > > > > don't conflict with old implementations, and preserve old > > > > implementations in the library too. To make the compiler generate calls > > > > to new implementations, one can add appropriate #define s in .h files. > > > > For GCC, __asm__ attribute also can be used. > > > > No, when new functions are added into the library, and binaries linked > > with the old library will continue to work with new library, version bump > > is not required. > > > > This is a standard rule. It was also recently discussed on -committers > > on Aug 20 in the thread > > Re: cvs commit: src/include histedit.h src/lib/libedit Makefile editline.3 el.c el.h > > In that discussion it has been said that datatype changes require a version > change. Now you're telling me that we should implement datatype changes as > new functions which consequently don't require a version change. So now the > policy is "version bump avoidance at all cost"? I am not setting any policy - I am not core. I am just suggesting it (strongly :-) Then, I believe that the cost here is relatively low compared to the benefit. libc is used by all programs, and version bumps would have quite severe impact. OTOH, you touch only half-dozen of functions, and they are not that popular, so why the change should affect all programs? Other OSes started to avoid version bumps. Linux promises to not bump the libc version since glibc2. NetBSD avoid version bumps too. (Linux use "symbol versioning", that isn't supported by our rtld.) > > > How else > > > do I know wich version x library has the new implementations (besides the > > > larger one :-)? > > > > Linker knows it. If some function ("new implementation") is missing, linker print > > an error message. This is all you need. > > I strongly disagree. Spitting "unresolved references" is *not* a way to > tell the user that he doesn't have the right libraries. I strongly disagree. This is much better than version bump. After all, we can add suggestion to upgrade libraries to the "unresolved references" message. Then, if an user don't have right libraries, it is his mistake. It should not impact another people. Also, we are not discussing _this_. A lot of functions were added to libc without a version bump, and it is a standard accepted practice (Just from top of my head: strlcpy, strlcat, mkstemps, strsignal, fseeko, ftello, poll, nanosleep, pread, pwrite, kld*, ... ouch, there is a lot of other functions). My suggestion have more serious disadvantages. For one, it add more work to you (the person who change an interface). But it save some work to everyone who will ever upgrade FreeBSD or deal with a 3rd party software. Then, say, dlsym(,"setjmp") will give probably incorrect result. But "you cannot have everything" and noone, I hope, will use such dlsym. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message