delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1997/05/30/09:30:10

From: loki AT dragoncat DOT net (Jeremy Blackman)
Subject: Re: Uname -m and arch
30 May 1997 09:30:10 -0700 :
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <Pine.LNX.3.95.970529224053.3269B-100000.cygnus.gnu-win32@herne.dragoncat.net>
Mime-Version: 1.0
Original-To: gnu-win32 AT cygnus DOT com
In-Reply-To: <199705292242.PAA00741@cirdan.cygnus.com>
Original-Sender: owner-gnu-win32 AT cygnus DOT com

On Thu, 29 May 1997, Geoffrey Noer wrote:

> > Under Linux, I would get i586. Is this as it should be? If so, what is
> > the meaning of 6395286?
> Either you have an Intel i6395286 chip in your machine or you're running
> into a cygwin.dll bug.  I have a hunch as to which is more likely.  :-)

Indeed.  Unless Intel's CPU design group has been -really- busy... :)

I noticed this problem under b17 as well, and reported it, but I suspect
it got lost in all the rush.  My solution for the moment was to write my
own 'arch' (for autoconf) and ignore the uname problem since it didn't
-break- anything. 

> What's happening is that uname() isn't setting the processor level
> correctly.  uname() gets some of its info using the SYSTEM_INFO struct.
> This structure has various members many of which aren't supported under
> both Windows 95 and NT.  :-(  I've fixed the development sources so uname
> will behave better under Windows 95 in future releases.

Perhaps a way to set this if you have a specific need, and default to i486
or something otherwise?  Unless you have a way to determine the chipset
accurately. :)  Only reason I suggest a way to set it is if you have
something which depends on 386, 486, or 586 compiler optimizations...

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


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