Re: [PATCH] Add native windows on arm64 support

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.

cheers

andrew

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