Thread

  1. Re: [PATCH] Add native windows on arm64 support

    Dave Cramer <davecramer@postgres.rocks> — 2024-01-29T16:20:18Z

    Dave Cramer
    www.postgres.rocks
    
    
    On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <andrew@dunslane.net> wrote:
    
    >
    > 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
    >
    
    Did you add the latest lock.patch ?
    
    Dave