From owner-freebsd-hackers Thu Sep 9 6: 0:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 1AC3E15133 for ; Thu, 9 Sep 1999 06:00:32 -0700 (PDT) (envelope-from marcel@scc.nl) Received: from scones.sup.scc.nl (i234.ztm.euronet.nl [194.134.67.35]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id OAA27468; Thu, 9 Sep 1999 14:59:38 +0200 (MET DST) Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id OAA79406; Thu, 9 Sep 1999 14:59:37 +0200 (CEST) (envelope-from marcel@scc.nl) Message-ID: <37D7AF39.ECC65D14@scc.nl> Date: Thu, 09 Sep 1999 14:59:37 +0200 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dmitrij Tejblum Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions References: <199909090953.NAA01806@tejblum.pp.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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"? Can someone tell me why we have the freakin' version numbers? > > 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. Now I know why Bruce doesn't believe in version numbers. They're probably the most misused objects in the universe :-( -- 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