View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016112CMakeCMakepublic2016-05-26 05:032016-06-10 14:31
ReporterGert Wollny 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
Platformi386 userspace on amd64OSDebian/ GNU/LinuxOS Versionsid
Product VersionCMake 3.5.2 
Target VersionFixed in Version 
Summary0016112: "uname -p" is a very poor choice to evaluate the CMAKE_*SYSTEM_PROCESSOR and may even be wrong
DescriptionWhen 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.
Additional InformationFor 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
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0041102)
Rolf Eike Beer (developer)
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 (reporter)
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 (administrator)
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.

- Issue History
Date Modified Username Field Change
2016-05-26 05:03 Gert Wollny New Issue
2016-05-26 05:23 Rolf Eike Beer Note Added: 0041102
2016-05-26 06:33 Gert Wollny Note Added: 0041103
2016-06-10 14:29 Kitware Robot Note Added: 0043008
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker