Content-Type: multipart/alternative;
 boundary="------------uQv8E4KYqbXp7kP9kEe6P1Os"
Message-ID: <98c8bcbe-3774-854c-b6a6-1c8e6992a25f@dunslane.net>
Date: Mon, 29 Jan 2024 11:16:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
To: Dave Cramer <davecramer@postgres.rocks>
Cc: Michael Paquier <michael@paquier.xyz>,
 Anthony Roberts <anthony.roberts@linaro.org>,
 Peter Eisentraut <peter@eisentraut.org>, Daniel Gustafsson
 <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>,
 Mike Holmes <mike.holmes@linaro.org>, Andres Freund <andres@anarazel.de>,
 Thomas Munro <thomas.munro@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Lina Iyer <lina.iyer@linaro.org>
References: 
 <CADK3HH+T0rQ58sYp0NnvkvopcEHA74Zmg=z7J5=skRrX+odnYw@mail.gmail.com>
 <ZbBMeMLXO0CtwY7X@paquier.xyz>
 <CADK3HHJ4uCsw0b5-c_HvYebHn1jQB-hV007Jf5c7FwGrCvDNSg@mail.gmail.com>
 <ZbGlFpeG-bPQIk-1@paquier.xyz>
 <70d20b11-8ed8-a34e-32d1-8f3015dd771b@dunslane.net>
 <CADK3HHK4RVz8oQXiQ_bYiUx1ZXWNbfF+=r5kJ8hhfU8+MD1DOQ@mail.gmail.com>
 <CAC1bJ4-tu8Ea0+D6sHdC_HuOSGbw6upFkr5B=eq_m0-2yf_-cg@mail.gmail.com>
 <CADK3HHJXwHLHk12m99TQ+cOF5BuJr2=C4xOhVFXmGEPLfC+7XA@mail.gmail.com>
 <5ba3cae0-0375-c3e6-4bce-89165e09bdd3@dunslane.net>
 <CADK3HHKs8PkPSU7vGKxcVq3qcHv95YDyOXz6DEGoS1o=tz7QRQ@mail.gmail.com>
 <ZbMLwGNw3rSJBYjh@paquier.xyz>
 <56da7612-9feb-c52f-1441-8fc4e51ca434@dunslane.net>
 <CADK3HHJgTqi7ZeKhBvegTk1=rzDYfGgEJqZN-hNMvQPAJ6R3PA@mail.gmail.com>
From: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: [PATCH] Add native windows on arm64 support
In-Reply-To: 
 <CADK3HHJgTqi7ZeKhBvegTk1=rzDYfGgEJqZN-hNMvQPAJ6R3PA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/98c8bcbe-3774-854c-b6a6-1c8e6992a25f%40dunslane.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------uQv8E4KYqbXp7kP9kEe6P1Os
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
>     On 2024-01-25 Th 20:32, Michael Paquier wrote:
>     > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>     >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan
>     <andrew@dunslane.net> wrote:
>     >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>     >>> Yeah, I think the default Developer Command Prompt for VS2022
>     is set up
>     >>> for x86 builds. AIUI you should start by executing "vcvarsall
>     x64_arm64".
>     >> Yup, now I'm in the same state you are
>     > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
>     > host and you'll be able to produce ARM64 builds, still these
>     will not
>     > be able to run on the host where they were built. How much of the
>     > patch posted upthread is required to produce such builds?  Basically
>     > everything from it, I guess, so as build dependencies can be
>     > satisfied?
>     >
>     > [1]:
>     https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>
>     If you look at the table here x86 and x64 are the only supported host
>     architectures. But that's OK, the x64 binaries will run on arm64 (W11
>     ARM64 has x64 emulation builtin). If that didn't work Dave and I
>     would
>     not have got as far as we have. But you want the x64_arm64
>     argument to
>     vcvarsall so you will get ARM64 output.
>
>
> I've rebuilt it using  x64_arm64 and with the attached (very naive 
> patch) and I still get an x64 binary :(


With this patch I still get a build error, but it's different :-)


[1406/2088] "link" @src/backend/postgres.exe.rsp
FAILED: src/backend/postgres.exe src/backend/postgres.pdb
"link" @src/backend/postgres.exe.rsp
    Creating library src\backend\postgres.exe.lib

storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol 
spin_delay referenced in function perform_spin_delay

src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

--------------uQv8E4KYqbXp7kP9kEe6P1Os
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2024-01-26 Fr 09:18, Dave Cramer
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CADK3HHJgTqi7ZeKhBvegTk1=rzDYfGgEJqZN-hNMvQPAJ6R3PA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr"><br>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Fri, 26 Jan 2024 at
              07:36, Andrew Dunstan &lt;<a
                href="mailto:andrew@dunslane.net" moz-do-not-send="true"
                class="moz-txt-link-freetext">andrew@dunslane.net</a>&gt;
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex"><br>
              On 2024-01-25 Th 20:32, Michael Paquier wrote:<br>
              &gt; On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer
              wrote:<br>
              &gt;&gt; On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan &lt;<a
                href="mailto:andrew@dunslane.net" target="_blank"
                moz-do-not-send="true" class="moz-txt-link-freetext">andrew@dunslane.net</a>&gt;
              wrote:<br>
              &gt;&gt;&gt; On 2024-01-25 Th 16:17, Dave Cramer wrote:<br>
              &gt;&gt;&gt; Yeah, I think the default Developer Command
              Prompt for VS2022 is set up<br>
              &gt;&gt;&gt; for x86 builds. AIUI you should start by
              executing "vcvarsall x64_arm64".<br>
              &gt;&gt; Yup, now I'm in the same state you are<br>
              &gt; Wait a minute here.  Based on [1], x64_arm64 means
              you can use a x64<br>
              &gt; host and you'll be able to produce ARM64 builds,
              still these will not<br>
              &gt; be able to run on the host where they were built. 
              How much of the<br>
              &gt; patch posted upthread is required to produce such
              builds?  Basically<br>
              &gt; everything from it, I guess, so as build dependencies
              can be<br>
              &gt; satisfied?<br>
              &gt;<br>
              &gt; [1]: <a
href="https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170"
                rel="noreferrer" target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170</a><br>
              <br>
              <br>
              If you look at the table here x86 and x64 are the only
              supported host <br>
              architectures. But that's OK, the x64 binaries will run on
              arm64 (W11 <br>
              ARM64 has x64 emulation builtin). If that didn't work Dave
              and I would <br>
              not have got as far as we have. But you want the x64_arm64
              argument to <br>
              vcvarsall so you will get ARM64 output.<br>
            </blockquote>
            <div><br>
            </div>
            <div>I've rebuilt it using  x64_arm64 and with the attached
              (very naive patch) and I still get an x64 binary :(</div>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>With this patch I still get a build error, but it's different :-)</p>
    <p><br>
    </p>
    <p>[1406/2088] "link" @src/backend/postgres.exe.rsp<br>
      FAILED: src/backend/postgres.exe src/backend/postgres.pdb<br>
      "link" @src/backend/postgres.exe.rsp<br>
         Creating library src\backend\postgres.exe.lib<br>
      <br>
      storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external
      symbol spin_delay referenced in function perform_spin_delay<br>
      <br>
      src\backend\postgres.exe : fatal error LNK1120: 1 unresolved
      externals<br>
    </p>
    <p><br>
    </p>
    <p>cheers</p>
    <p><br>
    </p>
    <p>andrew</p>
    <pre class="moz-signature" signature-switch-id="d0437855-2267-4610-80b3-83167ec45b0b" cols="72">--
Andrew Dunstan
EDB: <a class="moz-txt-link-freetext" href="https://www.enterprisedb.com">https://www.enterprisedb.com</a>
</pre>
  </body>
</html>

--------------uQv8E4KYqbXp7kP9kEe6P1Os--