View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014712 | CMake | CMake | public | 2014-01-20 09:45 | 2014-06-02 08:38 | ||||
Reporter | enricosorichetti | ||||||||
Assigned To | Brad King | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Apple Mac | OS | OS X | OS Version | 10.9.1 | ||||
Product Version | CMake 2.8.12.1 | ||||||||
Target Version | CMake 3.0 | Fixed in Version | CMake 3.0 | ||||||
Summary | 0014712: improper setting of CMAKE_HOST_SYSTEM_PROCESSOR | ||||||||
Description | On 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 Reproduce | run cmake --system-information | ||||||||
Additional Information | a 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" | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |