View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014712CMakeCMakepublic2014-01-20 09:452014-06-02 08:38
Reporterenricosorichetti 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformApple MacOSOS XOS Version10.9.1
Product VersionCMake 2.8.12.1 
Target VersionCMake 3.0Fixed in VersionCMake 3.0 
Summary0014712: improper setting of CMAKE_HOST_SYSTEM_PROCESSOR
DescriptionOn Apple Mac OS x 10.9.1 running on an
IMAC 2.93 GHz Intel Core 7

uname -m
reports ==> x86_64

while
cmake --system-information

reports ==> CMAKE_HOST_SYSTEM_PROCESSOR "i386"

should be ==> CMAKE_HOST_SYSTEM_PROCESSOR "x86_64"

Steps To Reproducerun
cmake --system-information
Additional Informationa quick fix could be
instead of ....
if(CMAKE_HOST_SYSTEM_NAME MATCHES "Linux|CYGWIN.*")
use ...
if(CMAKE_HOST_SYSTEM_NAME MATCHES "Linux|CYGWIN.*|Darwin")

tested in my environment/setup for my project
and provides the info as needed


on CENTOS 6.5 ( running as a VMWARE virtual machine)
cmake version 2.6-patch 4

cmake --system-information

correctly reports
==> CMAKE_HOST_SYSTEM_PROCESSOR "x86_64"
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0034969)
Rolf Eike Beer (developer)
2014-01-20 10:06

I bet your Centos-CMake is a 64 bit binary while the Mac one is 32 bit (or universal or whatever). In this case the information is correct.
(0034970)
Brad King (manager)
2014-01-20 10:09

It looks like a similar change to that proposed here was made for Cygwin for issue 0010774:

 Use 'uname -m' for processor on Cygwin
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2412d9bc [^]

Historically 'uname -m' gave a human-readable value on OS X:

 $ sw_vers
 ProductName: Mac OS X
 ProductVersion: 10.3.9
 BuildVersion: 7W98
 $ uname -m
 Power Macintosh
 $ uname -p
 powerpc

while 'uname -p' gave a more useful value. Since OS X changed to i386 they have been the same:

 $ sw_vers
 ProductName: Mac OS X
 ProductVersion: 10.4.11
 BuildVersion: 8S2167
 $ uname -m
 i386
 $ uname -p
 i386

 $ sw_vers
 ProductName: Mac OS X
 ProductVersion: 10.6
 BuildVersion: 10A432
 $ uname -m
 i386
 $ uname -p
 i386

Now with x86_64 they are different as reported in this issue:

 $ sw_vers
 ProductName: Mac OS X Server
 ProductVersion: 10.7.2
 BuildVersion: 11C74
 $ uname -m
 x86_64
 $ uname -p
 i386
(0034971)
Brad King (manager)
2014-01-20 10:12

Re 0014712:0034969: Even running a 64-bit CMake binary I get i386:

 $ file ../bin/cmake
 ../bin/cmake: Mach-O 64-bit executable x86_64
 $ ../bin/cmake ../../CMake/Tests/COnly
 $ grep CMAKE_HOST_SYSTEM_PROCESSOR CMakeFiles/*/CMakeSystem.cmake
 set(CMAKE_HOST_SYSTEM_PROCESSOR "i386")
(0034972)
enricosorichetti (reporter)
2014-01-20 10:24
edited on: 2014-01-20 10:25

I tend to disagree .... for many reasons :-)

1) the Intel core 7 is 64 bits
2 ) the mavericks kernel is 64 bits
3 ) for cmake
lipo -info cmake
Non-fat file: cmake is architecture: x86_64

4) the coding of CMakeDetermineSystem.cmake
CMAKE_HOST_SYSTEM_NAME MATCHES
is not matched against Darwin and the process fall down using
uname -p

but, since for linux uname -m is used,
there is no reason not to use the same for Darwin.

if You want to blame apple for reporting a i386 OK with me...
but since there is the right way to find out the proper machine/architecture
I do not see any reason not to use it

cheers
Enrico

(0034973)
Brad King (manager)
2014-01-20 10:36

Re 0014712:0034972: I never said we wouldn't fix this. I was just reporting the results of my investigation of the current situation.
(0034975)
enricosorichetti (reporter)
2014-01-20 12:03
edited on: 2014-01-20 12:04

Hi Brad,
our replies just crossed over

I was replying and disagreeing to/with the comment
>>> ... ... ... while the Mac one is 32 bit (or universal or whatever). ... ... ... <<<

also a solution that does not break the powerpc environment
could be

use uname -p
and if it reports a generic i386
then use
uname -m for the real thing

cheers
Enrico

(0034976)
Brad King (manager)
2014-01-20 12:25

This should fix it while still supporting ppc as a special case:

 OS X: Use 'uname -m' for processor
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d2a0900 [^]
(0036089)
Robert Maynard (manager)
2014-06-02 08:38

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-01-20 09:45 enricosorichetti New Issue
2014-01-20 10:06 Rolf Eike Beer Note Added: 0034969
2014-01-20 10:09 Brad King Note Added: 0034970
2014-01-20 10:12 Brad King Note Added: 0034971
2014-01-20 10:24 enricosorichetti Note Added: 0034972
2014-01-20 10:25 enricosorichetti Note Edited: 0034972
2014-01-20 10:36 Brad King Note Added: 0034973
2014-01-20 12:03 enricosorichetti Note Added: 0034975
2014-01-20 12:04 enricosorichetti Note Edited: 0034975
2014-01-20 12:25 Brad King Note Added: 0034976
2014-01-21 08:55 Brad King Assigned To => Brad King
2014-01-21 08:55 Brad King Status new => resolved
2014-01-21 08:55 Brad King Resolution open => fixed
2014-01-21 08:55 Brad King Fixed in Version => CMake 3.0
2014-01-21 08:55 Brad King Target Version => CMake 3.0
2014-06-02 08:38 Robert Maynard Note Added: 0036089
2014-06-02 08:38 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team