On 2024-01-29 Mo 11:20, Dave Cramer wrote:

Dave Cramer
www.postgres.rocks


On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <and...@dunslane.net> wrote:


    On 2024-01-26 Fr 09:18, Dave Cramer wrote:


    On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
    <and...@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
        <and...@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 ?




I'm a bit confused about exactly what needs to be applied. Can you supply a complete patch to be applied to a pristine checkout that will let me build?


cheers


andrew

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

Reply via email to