Date: Sat, 9 Nov 2002 11:18:13 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com>, "M. Warner Losh" <imp@bsdimp.com> Cc: ataraxia@cox.net, current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING Message-ID: <200211091118.13041.dfr@nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10211081806220.10745-100000@pcnet1.pcnet.com> References: <Pine.GSO.4.10.10211081806220.10745-100000@pcnet1.pcnet.com>
index | next in thread | previous in thread | raw e-mail
On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > In message: > > <Pine.GSO.4.10.10211081205020.27766-100000@pcnet1.pcnet.com> > > > > Daniel Eischen <eischen@pcnet1.pcnet.com> 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. > > 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 the first time ever, which can't run old binaries. Sorry, that isn't acceptable. The correct and robust way of doing things is to stop creating binaries (in both 4.x and 5.x) that reference __sF, then wait a full release cycle for the change to propagate. We can then remove the symbol in 6.x. In general, its a very poor idea to simply remove a feature that was supported in the last release of a package. The normal route is to deprecate (but still support) the feature in one release and remove it in the next. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211091118.13041.dfr>