<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>193043</bug_id>
          
          <creation_ts>2018-12-27 03:33:24 -0800</creation_ts>
          <short_desc>[CMake][WTF] Finesse i386 architecture detection</short_desc>
          <delta_ts>2018-12-28 05:02:32 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>CMake</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>INVALID</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Jim Mason">jmason</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>ews-watchlist</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1490892</commentid>
    <comment_count>0</comment_count>
    <who name="Jim Mason">jmason</who>
    <bug_when>2018-12-27 03:33:24 -0800</bug_when>
    <thetext>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 &apos;i386&apos; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490895</commentid>
    <comment_count>1</comment_count>
      <attachid>358107</attachid>
    <who name="Jim Mason">jmason</who>
    <bug_when>2018-12-27 04:18:49 -0800</bug_when>
    <thetext>Created attachment 358107
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490896</commentid>
    <comment_count>2</comment_count>
    <who name="EWS Watchlist">ews-watchlist</who>
    <bug_when>2018-12-27 04:21:18 -0800</bug_when>
    <thetext>Attachment 358107 did not pass style-queue:


ERROR: CMakeLists.txt:105:  No trailing spaces  [whitespace/trailing] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490897</commentid>
    <comment_count>3</comment_count>
      <attachid>358108</attachid>
    <who name="Jim Mason">jmason</who>
    <bug_when>2018-12-27 04:23:11 -0800</bug_when>
    <thetext>Created attachment 358108
Patch

Fixed style fault</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490906</commentid>
    <comment_count>4</comment_count>
      <attachid>358108</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2018-12-27 11:27:48 -0800</bug_when>
    <thetext>Comment on attachment 358108
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=358108&amp;action=review

&gt; CMakeLists.txt:98
&gt; +    # 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?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490909</commentid>
    <comment_count>5</comment_count>
    <who name="Jim Mason">jmason</who>
    <bug_when>2018-12-27 13:34:29 -0800</bug_when>
    <thetext>(In reply to Alexey Proskuryakov from comment #4)
&gt; How will we know in the future that this hack can be removed? Can you leave
&gt; 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 &apos;i386&apos; 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</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1490929</commentid>
    <comment_count>6</comment_count>
    <who name="Jim Mason">jmason</who>
    <bug_when>2018-12-28 05:02:18 -0800</bug_when>
    <thetext>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.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>358107</attachid>
            <date>2018-12-27 04:18:49 -0800</date>
            <delta_ts>2018-12-27 04:23:11 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>Patch</filename>
            <type>text/plain</type>
            <size>1344</size>
            <attacher name="Jim Mason">jmason</attacher>
            
              <data encoding="base64">SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDIzOTU1
NCkKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDEyIEBACisyMDE4LTEy
LTI3ICBKaW0gTWFzb24gIDxqbWFzb25AaWJpbnguY29tPgorCisgICAgICAgIFtDTWFrZV1bV1RG
XSBGaW5lc3NlIGkzODYgYXJjaGl0ZWN0dXJlIGRldGVjdGlvbgorICAgICAgICBodHRwczovL2J1
Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTkzMDQzCisKKyAgICAgICAgUmV2aWV3ZWQg
YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBDTWFrZUxpc3RzLnR4dDoKKwogMjAxOC0x
Mi0xOSAgQWRyaWFuIFBlcmV6IGRlIENhc3RybyAgPGFwZXJlekBpZ2FsaWEuY29tPgogCiAgICAg
ICAgIFtHVEtdIENhbm5vdCBidWlsZCB3aXRoIENNYWtlIDwzLjcKSW5kZXg6IENNYWtlTGlzdHMu
dHh0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0KLS0tIENNYWtlTGlzdHMudHh0CShyZXZpc2lvbiAyMzk1NTQpCisrKyBD
TWFrZUxpc3RzLnR4dAkod29ya2luZyBjb3B5KQpAQCAtOTUsNyArOTUsMTQgQEAKIGVsc2VpZiAo
TE9XRVJDQVNFX0NNQUtFX1NZU1RFTV9QUk9DRVNTT1IgTUFUQ0hFUyAiKHg2NHx4ODZfNjR8YW1k
NjQpIikKICAgICBzZXQoV1RGX0NQVV9YODZfNjQgMSkKIGVsc2VpZiAoTE9XRVJDQVNFX0NNQUtF
X1NZU1RFTV9QUk9DRVNTT1IgTUFUQ0hFUyAiKGlbMy02XTg2fHg4NikiKQotICAgIHNldChXVEZf
Q1BVX1g4NiAxKQorICAgICMgT24gc29tZSBPU2VzLCBgdW5hbWUgLXBgIGFsd2F5cyByZXBvcnRz
IGkzODYgZm9yIGFsbCBtZW1iZXJzCisgICAgIyBvZiB0aGUgSW50ZWwgcHJvY2Vzc29yIGZhbWls
eSwgd2hldGhlciAzMi0gb3IgNjQtYml0LiAgV2UgbXVzdAorICAgICMgaW5zcGVjdCB0aGUgcG9p
bnRlciBzaXplIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIGFyY2hpdGVjdHVyZS4KKyAgICBpZiAo
Q01BS0VfU0laRU9GX1ZPSURfUCBNQVRDSEVTIDgpCisgICAgICAgIHNldChXVEZfQ1BVX1g4Nl82
NCAxKQorICAgIGVsc2UgKCkKKyAgICAgICAgc2V0KFdURl9DUFVfWDg2IDEpCisgICAgZW5kaWYg
KCkgICAgCiBlbHNlaWYgKExPV0VSQ0FTRV9DTUFLRV9TWVNURU1fUFJPQ0VTU09SIE1BVENIRVMg
InBwYyIpCiAgICAgc2V0KFdURl9DUFVfUFBDIDEpCiBlbHNlaWYgKExPV0VSQ0FTRV9DTUFLRV9T
WVNURU1fUFJPQ0VTU09SIE1BVENIRVMgInBwYzY0IikK
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>358108</attachid>
            <date>2018-12-27 04:23:11 -0800</date>
            <delta_ts>2018-12-28 05:02:32 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>Patch</filename>
            <type>text/plain</type>
            <size>1340</size>
            <attacher name="Jim Mason">jmason</attacher>
            
              <data encoding="base64">SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDIzOTU1
NCkKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDEyIEBACisyMDE4LTEy
LTI3ICBKaW0gTWFzb24gIDxqbWFzb25AaWJpbnguY29tPgorCisgICAgICAgIFtDTWFrZV1bV1RG
XSBGaW5lc3NlIGkzODYgYXJjaGl0ZWN0dXJlIGRldGVjdGlvbgorICAgICAgICBodHRwczovL2J1
Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTkzMDQzCisKKyAgICAgICAgUmV2aWV3ZWQg
YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBDTWFrZUxpc3RzLnR4dDoKKwogMjAxOC0x
Mi0xOSAgQWRyaWFuIFBlcmV6IGRlIENhc3RybyAgPGFwZXJlekBpZ2FsaWEuY29tPgogCiAgICAg
ICAgIFtHVEtdIENhbm5vdCBidWlsZCB3aXRoIENNYWtlIDwzLjcKSW5kZXg6IENNYWtlTGlzdHMu
dHh0Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0KLS0tIENNYWtlTGlzdHMudHh0CShyZXZpc2lvbiAyMzk1NTQpCisrKyBD
TWFrZUxpc3RzLnR4dAkod29ya2luZyBjb3B5KQpAQCAtOTUsNyArOTUsMTQgQEAKIGVsc2VpZiAo
TE9XRVJDQVNFX0NNQUtFX1NZU1RFTV9QUk9DRVNTT1IgTUFUQ0hFUyAiKHg2NHx4ODZfNjR8YW1k
NjQpIikKICAgICBzZXQoV1RGX0NQVV9YODZfNjQgMSkKIGVsc2VpZiAoTE9XRVJDQVNFX0NNQUtF
X1NZU1RFTV9QUk9DRVNTT1IgTUFUQ0hFUyAiKGlbMy02XTg2fHg4NikiKQotICAgIHNldChXVEZf
Q1BVX1g4NiAxKQorICAgICMgT24gc29tZSBPU2VzLCBgdW5hbWUgLXBgIGFsd2F5cyByZXBvcnRz
IGkzODYgZm9yIGFsbCBtZW1iZXJzCisgICAgIyBvZiB0aGUgSW50ZWwgcHJvY2Vzc29yIGZhbWls
eSwgd2hldGhlciAzMi0gb3IgNjQtYml0LiAgV2UgbXVzdAorICAgICMgaW5zcGVjdCB0aGUgcG9p
bnRlciBzaXplIHRvIGRldGVybWluZSB0aGUgYWN0dWFsIGFyY2hpdGVjdHVyZS4KKyAgICBpZiAo
Q01BS0VfU0laRU9GX1ZPSURfUCBNQVRDSEVTIDgpCisgICAgICAgIHNldChXVEZfQ1BVX1g4Nl82
NCAxKQorICAgIGVsc2UgKCkKKyAgICAgICAgc2V0KFdURl9DUFVfWDg2IDEpCisgICAgZW5kaWYg
KCkKIGVsc2VpZiAoTE9XRVJDQVNFX0NNQUtFX1NZU1RFTV9QUk9DRVNTT1IgTUFUQ0hFUyAicHBj
IikKICAgICBzZXQoV1RGX0NQVV9QUEMgMSkKIGVsc2VpZiAoTE9XRVJDQVNFX0NNQUtFX1NZU1RF
TV9QUk9DRVNTT1IgTUFUQ0hFUyAicHBjNjQiKQo=
</data>

          </attachment>
      

    </bug>

</bugzilla>