Re: [PATCH] Add native windows on arm64 support

On 2024-01-30 Tu 17:54, Dave Cramer wrote:
>
>
>
> On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan <andrew(at)dunslane(dot)net>
> wrote:
>
>
> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>>
>>
>> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan
>> <andrew(at)dunslane(dot)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
>>> <andrew(at)dunslane(dot)net> wrote:
>>>
>>>
>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>>
>>>>
>>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan
>>>> <andrew(at)dunslane(dot)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(at)dunslane(dot)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-f9b532bb6f56@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