" `uname -m' currently reports `i686-AT386', compared to `i686' on
GNU/Linux. Is there a reason to be different? "
I have the same question too! :)
It's easy to make 'uname' show just the machine name and not the
ugly '-AT386' part. This is how
se what best fits the presumptions of any packages that use
> uname -m and do NOT use config.guess.
Depends on what you mean with difficult. config.guess is copied into
thousands of source packages, and updating it is a PITA in the context of,
for example, Debian GNU/Hurd.
However, I don't rea
> I think that maybe the definition of reasonable might just as well be:
> whatever config.guess can deal with.
We can get config.guess changed without difficulty. So I think that we
should choose what best fits the presumptions of any packages that use
uname -m and do NOT use config
On Fri, May 24, 2002 at 12:26:15PM +0200, Robert Millan wrote:
> Change it if you feel it should be, but consider some Makefiles out there
> are currently reliying on uname -m for their filenaming conventions
> (see any Jorg Schilling program for example, now being ported)
Of course th
l those values were chosen a very long
> time ago at CMU and don't necessarily mean a whole lot useful now.
> It would be fine to change how we decide what to put in utsname.machine.
Change it if you feel it should be, but consider some Makefiles out there
are currently reliying on
The utsname.machine string is chosen in proc/host.c:initialize_version_info.
Mach's host_basic_info gives you integers for "CPU type" and "CPU subtype",
with constants defined in . Our file proc/cpu-types.c
gives string names to these, and we use "type-subtype" as the
utsname.machine string. The
Hi,
this comes up from time to time in porting issues when configuration and
wanna-be scripts parse the output of uname -m.
On GNU/Linux, this gives "i686" here.
On GNU/Hurd, it gives "i386-AT386".
Usually easy enough to fix, but does anybody remember what the AT386 stands
