Date: Sat, 2 Nov 2002 16:19:10 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: "Matthew N. Dodd" <winter@jurai.net> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, Mark Murray <mark@grondar.org>, freebsd-current@FreeBSD.ORG Subject: Re: __sF Message-ID: <20021102161910.A75837@FreeBSD.org> In-Reply-To: <20021102183431.V35807-100000@sasami.jurai.net>; from winter@jurai.net on Sat, Nov 02, 2002 at 06:36:31PM -0500 References: <20021102233215.GA30122@troutmask.apl.washington.edu> <20021102183431.V35807-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: "Matthew N. Dodd" <winter@jurai.net> [ Data: 2002-11-02 ] [ Subjecte: Re: __sF ] > On Sat, 2 Nov 2002, Steve Kargl wrote: > > On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote: > > > This isn't the case for one piece of vendor software that I'm not allowed > > > to talk about. > > > > See the new WANT_COMPAT4_STDIO make.conf knob. > > This won't be acceptable as the vender will likely not be producing a > separate 5.0 build (ie the same build needs to run on both.) until 4.x is > EOLed. Forcing people to rebuild libc seems a high barrier to entry. Not making a clean break by default (i.e. not requiring a rebuild to get the backwards behaviour) causes this to cascade. "But it worked in 4.x" => "Well then by golly it will in 5.0!" "But it works in 5.0" => "Then we'll keep it around for 5.x" "But it worked in 5.x!" => "We'll make it tunable (on), but have rtld whine!" "But it worked in 6.0, despite that rtld bug!" etc. Look how long it took Microsoft to deprecate MS DOS apps. It took until they switched to an entirely new kernel (for the product line) and rebadged the hell out of it. I much prefer the idea of "move onward, provide a backward solution if someone really needs it"... Would it satisfy you to see a port, h0h0libc? Solutions like that can't be guaranteed to work for (N+X).0 systems, to provide vendor _libraries_ to link in a non-cross environment, where N is the system the libraries are for, and where X is some number greater than one. Keep in mind this only affects linking a closed library, and that this situation is a bit absurd, given that a reasonable solution exists, and if necessary, can be packaged up nicely... Developers using this sort of environment are asking for trouble. It seems to me a serious developer will develop where the tools are working and supported (keep in mind this is a issue with a vendor LIBRARY being LINKED in, not a TOOL being USED), or set up a proper cross-env to target the platform where the library is targettted, or will force their vendor to support the new platform they (for whatever reason) see fit to develop on. [ I promise the rest of this won't be something someone will try to construe as a bikeshed. ] juli. -- Juli Mallett <jmallett@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021102161910.A75837>