X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f Date: Thu, 27 Dec 2001 10:52:31 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: djgpp-workers AT delorie DOT com Subject: Re: RFD - UNAME_MACHINE ? In-Reply-To: <10112262228.AA14172@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 26 Dec 2001, Charles Sandmann wrote: > > > > By the way, we really need some compatibility environment variable > > > > (or something) to allow uname in 2.04 to provide 2.03 behavior ... > > > > > > Why? What is the problem? > > > > Older sources (read much of what's on Simtel today in source) won't build > > using the new uname without hacking. Someday I see wanting to build some > > of these with CVS/2.04 release without needing to hand replace images like > > uname. It would be convenient to have a flag in the environment to fall > > back to machine being "PC" instead of i?86. I agree with DJ and Tim: there are better solutions to this nuisance than an environment variable. > Another example - non-support of i786 / i886 whatever - if we had an > environment variable which could override, then you could set it to be > i686 and continue. This isn't different from any other x86-based platforms. Why should our solutions be different? > How about an environment variable UNAME_MACHINE - if defined we use it > instead of the CPU detection? Allows you to make it "pc" for old v2.03 > compatibility or "i586" for builds that don't know about new chips. You can have this by passing a suitable argument to ./configure.