From owner-freebsd-current Sat Nov 9 3:18:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A6F37B401 for ; Sat, 9 Nov 2002 03:18:54 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F9C43E42 for ; Sat, 9 Nov 2002 03:18:46 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gA9BIDVu016974; Sat, 9 Nov 2002 11:18:13 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Daniel Eischen , "M. Warner Losh" Subject: Re: [PATCH] note the __sF change in src/UPDATING Date: Sat, 9 Nov 2002 11:18:13 +0000 User-Agent: KMail/1.4.3 Cc: ataraxia@cox.net, current@FreeBSD.ORG References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211091118.13041.dfr@nlsystems.com> X-Spam-Status: No, hits=-7.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08, USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > In message: > > > > > > Daniel Eischen writes: > > : All the ports are going to be rebuilt for the release anyways, > > : so this doesn't affect fresh installs, correct? It is only a > > : problem when mixing older 4.x and 5.0 libraries/binaries with > > : __sF-free libc (if I understand things correctly). > > > > The problem is that you cannot have 4.x packages and 5.x packages > > co-mingled on the same system. that's what I'm trying to fix.=20 > > You'd have to rebuild the 4.x packages before they are fixed. > > I don't think this is a show-stopper. Just recompile all your > ports or use the pre-built 5.0 packages. > > > : This is 5.0; it is a major release and there will be some flies > > : in the ointment. I say bite the bullet now -- don't wait. > > : If we want to provide an optional compatability hack to libc > > : so that folks can compile it with __sF support, then I think > > : that is better than leaving __sF in the release, perhaps > > : with a mktemp(3)-like warning if possible (?). > > > > You'd need a run-time warning for this to be effective. I'm not > > sure that ld.so can do this right now. > > Could you put __sF in it's own file, and put the error in > a .init section? We don't care about static binaries, right? > They shouldn't have a problem. > > > This is not a fly in the pointment, but rather a major > > incompatibility that makes it impossible to have a reasonable mix. > > If it's really a hassle for folks, then just provide the > optional compatability hack and make them rebuild libc. > Or provide a pre-built version that doesn't get installed > by default. So what you are saying, basically, is that we should ship a release, for=20 the first time ever, which can't run old binaries. Sorry, that isn't=20 acceptable. The correct and robust way of doing things is to stop=20 creating binaries (in both 4.x and 5.x) that reference __sF, then wait=20 a full release cycle for the change to propagate. We can then remove=20 the symbol in 6.x.=20 In general, its a very poor idea to simply remove a feature that was=20 supported in the last release of a package. The normal route is to=20 deprecate (but still support) the feature in one release and remove it=20 in the next. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message