Re: [PATCH] Add native windows on arm64 support

On Wed, 31 Jan 2024 at 10:21, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> 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
>>>
>>>
>>> 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>
> <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
>
>

Thanks, this patch works and
testing with meon passes.

I'll try the buildfarm next.

Dave