MantisBT - CMake
View Issue Details
0016112CMakeCMakepublic2016-05-26 05:032016-06-10 14:31
Gert Wollny 
Kitware Robot 
normalminorhave not tried
closedmoved 
i386 userspace on amd64Debian/ GNU/Linuxsid
CMake 3.5.2 
 
0016112: "uname -p" is a very poor choice to evaluate the CMAKE_*SYSTEM_PROCESSOR and may even be wrong
When running cmake in a i386 user space on top of an amd64 kernel the reported processor type may be X86_64 instead of i386, as it so happens with DCMTK as shown by the reproducible build effort:

https://tests.reproducible-builds.org/rb-pkg/testing/i386/dcmtk.html [^]

In the case of DCMTK this is of no serious consequence, but other projects might use this value for compile time decisions that could result in code that can not actually be run on the selected target architecture.
For a further discussion see also:

https://stackoverflow.com/questions/11944060/how-to-detect-target-architecture-using-cmake [^]

There is also a link to code that might be used to estimate the host arch based on try_compile.

best,
Gert
No tags attached.
Issue History
2016-05-26 05:03Gert WollnyNew Issue
2016-05-26 05:23Rolf Eike BeerNote Added: 0041102
2016-05-26 06:33Gert WollnyNote Added: 0041103
2016-06-10 14:29Kitware RobotNote Added: 0043008
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0041102)
Rolf Eike Beer   
2016-05-26 05:23   
"uname -p" is seldomly used, only for systems which neither match "Linux|CYGWIN.*|Darwin|^GNU$" not "OpenBSD". The documentation is misleading at this point.

Please also note that on that stack overflow question the statement in the original question that says CMAKE_SIZEOF_VOID_P is of the host system is actually wrong, it is the size of the target system.
(0041103)
Gert Wollny   
2016-05-26 06:33   
Okay, then maybe the title of the bug report should be changed, but still, whatever cmake actually does to obtain the target processor doesn't provide the correct answer in this case.

After digging a bit through the code it seems that you use the uname(2) system call in Source/kwsys/SystemInformation.cxx to obtain the machine information, and if this information is used as target in the non-cross-compile case, than it seems that the machine info does not reflect the 32 bit i686 environment that is run on top of the x86_64 kernel.

Whether this is a bug or a feature of uname(2), who's to decide ...
(0043008)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.