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 > > > 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. Dave
0001-fix-build-for-arm.patch
Description: Binary data
0002-naive-patch-to-fix-locking-for-arm64.patch
Description: Binary data