On 2024-01-30 Tu 09:50, Dave Cramer wrote:


On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <and...@dunslane.net> wrote:


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

    Dave Cramer
    www.postgres.rocks <http://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


See attached.



No, that is what is giving me the error shown above (just tried again to be certain). And it's not surprising, as patch 2 #ifdef's out the definition of spin_delay().

If you can get a complete build with these patches then I suspect you're not doing a proper ARM64 build.


cheers


andrew

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

Reply via email to