delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/12/26/17:26:45

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10112262228.AA14172@clio.rice.edu>
Subject: RFD - UNAME_MACHINE ?
To: djgpp-workers AT delorie DOT com
Date: Wed, 26 Dec 2001 16:28:30 -0600 (CST)
In-Reply-To: <10112262044.AA17887@clio.rice.edu> from "Charles Sandmann" at Dec 26, 2001 02:44:06 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
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

> 
> > > 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.
> 
> When building with 2.03 this is OK (unless a new distribution requires the
> new uname...), but contrary to popular belief we will get 2.04 released 
> someday :-)

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.

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019