* De: "Matthew N. Dodd" <[EMAIL PROTECTED]> [ 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 <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
