Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rUwzq-00Dyxn-49 for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2024 22:54:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rUwzo-00ACJ1-AO for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jan 2024 22:54:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rUwzn-00ACH9-Nk for pgsql-hackers@lists.postgresql.org; Tue, 30 Jan 2024 22:54:23 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rUwzg-004E6C-0r for pgsql-hackers@lists.postgresql.org; Tue, 30 Jan 2024 22:54:22 +0000 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 5A5C62034D for ; Tue, 30 Jan 2024 17:54:15 -0500 (EST) Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2cf4fafa386so50492641fa.1 for ; Tue, 30 Jan 2024 14:54:15 -0800 (PST) X-Gm-Message-State: AOJu0Yxie3t3IMAskp2masu7w8zz2QIT0a/rwJ6J/ElrtYARox2C1MuB x0u7vXmyU20A656ITxkJnwcbnWvSfvtVPH+RsLfvv2mpNJ3YlxGRDA38QZhZxNhYa6ntjErKgp9 HoVC8T+la6wV2R+6MDU9uPzZ1cK4= X-Google-Smtp-Source: AGHT+IFAg4rAZ/mOdrJxiL5X4rVoaH0yoBJOxjC4UI9gz9NeOJDBe4edfAUfEu+w/A8gEgwn4mtU4zwdtrQa6f4jC+A= X-Received: by 2002:a2e:b1c5:0:b0:2ce:dfc:db78 with SMTP id e5-20020a2eb1c5000000b002ce0dfcdb78mr6613469lja.29.1706655253438; Tue, 30 Jan 2024 14:54:13 -0800 (PST) MIME-Version: 1.0 References: <70d20b11-8ed8-a34e-32d1-8f3015dd771b@dunslane.net> <5ba3cae0-0375-c3e6-4bce-89165e09bdd3@dunslane.net> <56da7612-9feb-c52f-1441-8fc4e51ca434@dunslane.net> <98c8bcbe-3774-854c-b6a6-1c8e6992a25f@dunslane.net> <866cfd73-18f4-643c-88d2-a77a8045a965@dunslane.net> In-Reply-To: <866cfd73-18f4-643c-88d2-a77a8045a965@dunslane.net> From: Dave Cramer Date: Tue, 30 Jan 2024 17:54:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Add native windows on arm64 support To: Andrew Dunstan Cc: Andres Freund , Anthony Roberts , Daniel Gustafsson , Lina Iyer , Michael Paquier , Mike Holmes , Peter Eisentraut , PostgreSQL Hackers , Thomas Munro , Tom Lane Content-Type: multipart/alternative; boundary="00000000000022a703061031a482" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000022a703061031a482 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2024 at 4:56=E2=80=AFPM Andrew Dunstan wrote: > > On 2024-01-30 Tu 09:50, Dave Cramer wrote: > > > > On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan 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 wrote= : >> >>> >>> On 2024-01-26 Fr 09:18, Dave Cramer wrote: >>> >>> >>> >>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan >>> 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 >>>> 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 no= t >>>> > 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-li= ne?view=3Dmsvc-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 suppl= y >> 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 Dave > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > --00000000000022a703061031a482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Jan 30, 2024 at 4:56=E2=80=AFPM Andre= w Dunstan <andrew@dunslane.net> wrote:
=20 =20 =20


On 2024-01-30 Tu 09:50, Dave Cramer wrote:
=20


On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan <andrew@dunslane.net> wrote:


On 2024-01-29 Mo 11:20, Dave Cramer wrote:

Dave Cramer


On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan <andrew@dunslane.net> wrote:


On 2024-01-26 Fr 09:18, Dave Cramer wrote:


On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan <andrew@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 <andrew@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.=C2=A0 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.=C2=A0 How much of the > patch posted upthread is required to produce such builds?=C2=A0 Basically > everything from it, I guess, so as build dependencies can be
> satisfied?
>
> [1]: https://learn.microsoft.com/en-us/cpp/bui= ld/building-on-the-command-line?view=3Dmsvc-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=C2=A0 x64_ar= m64 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 =C2=A0=C2=A0 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&= #39;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

Dave=C2=A0


cheers


andrew

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