On Wed, 31 Jan 2024 at 10:21, Andrew Dunstan <and...@dunslane.net> wrote:
> > On 2024-01-30 Tu 17:54, Dave Cramer wrote: > > > > > On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <and...@dunslane.net> > wrote: > >> >> 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 >>> >>> >>> 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. >> > > Okay I will look when I get home in a week > > > I made some progress. The attached is mostly taken from > <https://postgr.es/m/dbee741f-b9b7-a0d5-1b1b-f9b532bb6...@linaro.org> > <https://postgr.es/m/dbee741f-b9b7-a0d5-1b1b-f9b532bb6...@linaro.org> > > With it applied I was able to get a successful build using the buildfarm > client. However, there are access violations when running some tests, so > there is still some work to do, apparently. > > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > Thanks, this patch works and testing with meon passes. I'll try the buildfarm next. Dave
