Opened 7 years ago

Closed 7 years ago

#41070 closed defect (wontfix)

cmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting

Reported by: hjj@… Owned by: cssdev
Priority: Normal Milestone:
Component: ports Version: 2.2.0
Keywords: Cc: ryandesign (Ryan Schmidt)
Port: cmake

Description (last modified by ryandesign (Ryan Schmidt))

A test directory with a CMakeLists.txt with this one line:

message("-- Processor type        : ${CMAKE_HOST_SYSTEM_PROCESSOR}")

returns (among all the other info) when doing "cmake .":

-- Processor type        : i386

However "uname -m" returns the correct x86_64 (on my MacBook Pro with i7 cpu). This is a big problem in our computational chemistry software development, where we use cmake to identify correct libraries, compilers, compiler flags etc. (project: http://daltonprogram.org) A colleague in USA suggests that we switch to homebrew to solve the problem of getting cmake to do the correct thing on both linux and darwin systems without dirty tricks, as testing for darwin and ports and then change explicitly to x86_64. I hope that I instead can persuade you to fix the problem.

Change History (4)

comment:1 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added
Description: modified (diff)
Keywords: cmake removed
Owner: changed from macports-tickets@… to css@…
Port: cmake added
Summary: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting in cmakecmake: Wrong CMAKE_SYSTEM_HOST_PROCESSOR setting

Are you saying that Homebrew's cmake correctly identifies the processor? Or that a cmake compiled from the official sources does so? I would rather expect this to be an upstream issue, if it is an issue at all (I don't know what the developers intend for CMAKE_SYSTEM_HOST_PROCESSOR to represent).

Note that "uname" does not necessarily tell you the best architecture to compile for, nor necessarily a valid architecture at all. On the PowerBook G4 I'm using today, "uname -m" says "Power Macintosh" whereas "uname -p" says "powerpc"; neither of those are valid PowerPC architectures (which would be something like "ppc" or "ppc7450"). On some early Intel Macs, "uname" might say "i386" because the computer uses a 32-bit kernel, while nevertheless being completely capable of running 64-bit usermode programs.

Why do you need to know the architecture? If you don't specify one, the compiler will use a reasonable default architecture.

comment:2 in reply to:  description Changed 7 years ago by larryv (Lawrence Velázquez)

Resolution: invalid
Status: newclosed

Replying to hjj@…:

A colleague in USA suggests that we switch to homebrew to solve the problem of getting cmake to do the correct thing on both linux and darwin systems without dirty tricks, as testing for darwin and ports and then change explicitly to x86_64. I hope that I instead can persuade you to fix the problem.

No. The problem is that you are using CMAKE_HOST_SYSTEM_PROCESSOR incorrectly.

If you are not cross-compiling, CMAKE_HOST_SYSTEM_PROCESSOR is equivalent to CMAKE_SYSTEM_PROCESSOR, which is defined to be the output of uname -p on *nix systems, not uname -m. On my 10.8.5 machine:

% /usr/bin/uname -p
i386

If CMAKE_HOST_SYSTEM_PROCESSOR does not provide the information you require, then you need to find another way of obtaining that information.

comment:3 Changed 7 years ago by larryv (Lawrence Velázquez)

Resolution: invalid
Status: closedreopened

comment:4 Changed 7 years ago by larryv (Lawrence Velázquez)

Resolution: wontfix
Status: reopenedclosed
Note: See TracTickets for help on using tickets.