|Summary:||[CMake][WTF] Finesse i386 architecture detection|
|Product:||WebKit||Reporter:||Jim Mason <jmason>|
|Version:||WebKit Nightly Build|
Description Jim Mason 2018-12-27 03:33:24 PST
WTF processor architecture is being determined via CMAKE_SYSTEM_PROCESSOR. On systems which support uname, this is initialized to `uname -p`. However, the tricky bit is that on some OSes, `uname -p` returns 'i386' for both 32-bit and 64-bit members of the Intel processor family. Thus, in this case, we must check the pointer size to determine the actual architecture.
Comment 2 EWS Watchlist 2018-12-27 04:21:18 PST
Attachment 358107 [details] did not pass style-queue: ERROR: CMakeLists.txt:105: No trailing spaces [whitespace/trailing]  Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Jim Mason 2018-12-27 04:23:11 PST
Created attachment 358108 [details] Patch Fixed style fault
Comment 4 Alexey Proskuryakov 2018-12-27 11:27:48 PST
Comment on attachment 358108 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=358108&action=review > CMakeLists.txt:98 > + # On some OSes, `uname -p` always reports i386 for all members How will we know in the future that this hack can be removed? Can you leave any pointers at all?
Comment 5 Jim Mason 2018-12-27 13:34:29 PST
(In reply to Alexey Proskuryakov from comment #4) > How will we know in the future that this hack can be removed? Can you leave > any pointers at all? There is no intention that this should ever be removed; it is necessary because of the semantics of uname -p: https://en.wikipedia.org/wiki/Uname As can be observed from the link above, many operating systems return 'i386' for `uname -p` although they are in fact 64-bit. For correct operation, it must be checked in this case whether the target is actually 32- or 64-bits. See for example: https://cmake.org/pipermail/cmake/2007-March/013134.html
Comment 6 Jim Mason 2018-12-28 05:02:18 PST
I am going to withdraw this patch for now. CMAKE_SYSTEM_PROCESSOR is not ideal, as i386 is ambiguous; however, I am not sure there is a best-practices alternative for architecture determination in CMake. As for the patch, my doubt is whether CMAKE_SIZEOF_VOID_P will yield the expected result if the target architecture is different to the build architecture. For now, users who are affected by the i386 ambiguity can override the value of CMAKE_SYSTEM_PROCESSOR to work within the existing semantics. That is not ideal, but now I can think of no better way that does not introduce some other problem.