Re: [PATCH] Add native windows on arm64 support

2024-01-25 Thread Anthony Roberts
Hi David,

Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.

Thanks,
Anthony

On Thu, 25 Jan 2024, 21:01 Dave Cramer,  wrote:

>
>
> On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  wrote:
>
>>
>> On 2024-01-24 We 19:02, Michael Paquier wrote:
>>
>> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>>
>> I managed to get it to build the vcvarsall arch needs to be x64. I need to
>> add some options, but the patch above needs to be applied to build it.
>>
>> Nice.  If I may ask, what kind of host and/or configuration have you
>> used to reach a state where the code can be compiled and run tests
>> with meson?  If you have found specific steps, it may be a good thing
>> to document that on the wiki, say around [1].
>>
>> Perhaps you have not included TAP?  It may be fine in terms of runtime
>> checks and coverage.
>>
>> [1]: 
>> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>>
>>
>>
>> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we
>> really want to build with x64_arm64, i.e. to generate native arm64
>> binaries. Setting just x64 will not do that, AIUI.
>>
>> I tried that with the buidfarm, setting that in the config file's call to
>> PGBuild::VSenv::getenv().
>>
>> That upset msvc_gendef.pl, so I added this there to keep it happy:
>>
>> $arch = 'x86_64' if $arch eq 'aarch64';
>>
>> After that things went ok until I got this:
>>
>> [1453/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
>> _mm_pause referenced in function perform_spin_delay
>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>
>>
>> I haven't made further progress, but I will return to it in the next day
>> or so.
>>
>> While this will be nice to have, I think it won't really matter until
>> there is ARM64 support in released versions of Windows Server. AFAICT they
>> still only sell versions for x86_64
>>
>
> I've tried it with my patch attached previously and x64_arm64 and it works
> fine. builds using the buildfarm as well.
>
> Is there a definitive way to figure out if the binaries are x64_arm64
>
> Dave
>


Re: [PATCH] Add native windows on arm64 support

2023-09-19 Thread Anthony Roberts

Hi,

This was covered earlier in the thread - I have taken this on in Niyas' 
stead.


Was there an explicit request for something there? I was under the 
impression that this was all just suggestion/theory at the moment.


Thanks,
Anthony

On 19/09/2023 09:33, Peter Eisentraut wrote:

On 14.09.23 11:39, Daniel Gustafsson wrote:
On 13 Sep 2023, at 21:12, Peter Eisentraut  
wrote:


On 31.08.23 06:44, Tom Lane wrote:

I agree.  I'm really uncomfortable with claiming support for
Windows-on-ARM if we don't have a buildfarm member testing it.
For other platforms that have a track record of multiple
hardware support, it might not be a stretch ... but Windows was
so resolutely Intel-only for so long that "it works on ARM" is
a proposition that I won't trust without hard evidence. There
are too many bits of that system that might not have gotten the
word yet, or at least not gotten sufficient testing.
My vote for this is we don't commit without a buildfarm member.


I think we can have a multi-tiered approach, where we can commit 
support but consider it experimental until we have buildfarm coverage.


If it's experimental it should probably be behind an opt-in flag in
autoconf/meson, or be reverted by the time REL_17_STABLE branches unless
coverage has materialized by then.


The author's email is bouncing now, due to job change, so it's 
unlikely we will see any progress on this anymore.  I am setting it to 
returned with feedback.







Re: [PATCH] Add native windows on arm64 support

2023-08-30 Thread Anthony Roberts
Hi,

Just a follow-up: having spoken to the relevant people, sadly, right now,
we do not have the capacity to be pulling machines out of our day-to-day CI
tasks to dedicate to specific projects.

I can, however, offer a few alternatives:

1. If you have capacity on your linux x64 machines, it is possible to
emulate WoA, and run tests that way:
https://www.linaro.org/blog/emulate-windows-on-arm/
This is something that works well for projects that we have contributed it
to (ie, sse2neon uses it via github actions) - if you run into any issues
with this, we are able to try and fix them on our side, as likely more than
postgres would benefit.

2. If there is any scope for it on your side at all, a Samsung Galaxy Book
Go 14" can be had from ebay for ~£140.
Understandably, this might not be an option for you.

If it helps, if this is merged, we do have the possibility of running our
own downstream CI builds nightly for the tip of your main branch here:
https://gitlab.com/Linaro/windowsonarm/nightly
This is something we do for a few projects that do not have full upstream
CI.

Thanks,
Anthony


On Fri, 25 Aug 2023 at 11:34, Anthony Roberts 
wrote:

> Thanks for the link - that looks basically the same as what we do for
> CMake (option 2), so should be relatively easy.
>
> I will have a chat to relevant people about setting a machine up
> properly for it.
>
> Thanks,
> Anthony
>
> On 25/08/2023 11:17, Michael Paquier wrote:
> > On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:
> >> Which of these are you looking for us to provide:
> >>
> >> * A machine for you to directly access (via a VPN)
> >> * A machine we just run a worker script on that automatically picks up
> the
> >> builds as required
> >> * Us to do downstream CI
> >>
> >> All are possible, but preferably not option 1, as it would mean
> straight up
> >> pulling out a machine from our build farm, and it has to go through all
> >> sorts of approvals internally. If it's the only way forward I can kick
> it up
> >> the chain though.
> >>
> >> Option 2 and 3 are ones we do for various other projects (ie. 2 -
> CMake, 3 -
> >> OpenSSL)
> > The community has its own CI facility.  Here is a link of how to set
> > up a machine:
> > https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
> >
> > And all the results are published by the maintainers of the machines
> > on a periodic basis where the buildfarm client code is set:
> > https://buildfarm.postgresql.org/cgi-bin/show_status.pl
> >
> > The final result would be for you to maintain the machine so as we are
> > able to see if anything breaks with it.  Adding extra dependencies to
> > the build like OpenSSL would be nice, but based on the contents of the
> > patch to add this port that does not seem mandatory to me, either.
> >
> > Once the machine is ready, you will need to request a buildfarm
> > machine name and a key to be able to begin publishing the reports of
> > the builds to the community buildfarm.  Once the machine is ready to
> > go, just let me know and I'd be OK to merge the patch (I still want to
> > do a final review of it in case I've missed something, but I can move
> > on with that before the buildfarm machine is set up).
> > --
> > Michael
>


Re: [PATCH] Add native windows on arm64 support

2023-08-25 Thread Anthony Roberts
Thanks for the link - that looks basically the same as what we do for 
CMake (option 2), so should be relatively easy.


I will have a chat to relevant people about setting a machine up 
properly for it.


Thanks,
Anthony

On 25/08/2023 11:17, Michael Paquier wrote:

On Fri, Aug 25, 2023 at 10:40:39AM +0100, Anthony Roberts wrote:

Which of these are you looking for us to provide:

* A machine for you to directly access (via a VPN)
* A machine we just run a worker script on that automatically picks up the
builds as required
* Us to do downstream CI

All are possible, but preferably not option 1, as it would mean straight up
pulling out a machine from our build farm, and it has to go through all
sorts of approvals internally. If it's the only way forward I can kick it up
the chain though.

Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 3 -
OpenSSL)

The community has its own CI facility.  Here is a link of how to set
up a machine:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto

And all the results are published by the maintainers of the machines
on a periodic basis where the buildfarm client code is set:
https://buildfarm.postgresql.org/cgi-bin/show_status.pl

The final result would be for you to maintain the machine so as we are
able to see if anything breaks with it.  Adding extra dependencies to
the build like OpenSSL would be nice, but based on the contents of the
patch to add this port that does not seem mandatory to me, either.

Once the machine is ready, you will need to request a buildfarm
machine name and a key to be able to begin publishing the reports of
the builds to the community buildfarm.  Once the machine is ready to
go, just let me know and I'd be OK to merge the patch (I still want to
do a final review of it in case I've missed something, but I can move
on with that before the buildfarm machine is set up).
--
Michael





Re: [PATCH] Add native windows on arm64 support

2023-08-25 Thread Anthony Roberts

Hi,

Which of these are you looking for us to provide:

* A machine for you to directly access (via a VPN)
* A machine we just run a worker script on that automatically picks up 
the builds as required

* Us to do downstream CI

All are possible, but preferably not option 1, as it would mean straight 
up pulling out a machine from our build farm, and it has to go through 
all sorts of approvals internally. If it's the only way forward I can 
kick it up the chain though.


Option 2 and 3 are ones we do for various other projects (ie. 2 - CMake, 
3 - OpenSSL)


Thanks,
Anthony

On 17/08/2023 23:28, Michael Paquier wrote:

On Thu, Aug 17, 2023 at 09:41:44AM +0100, Anthony Roberts wrote:

Just following up on this, has there been any movement?

I did see another message go into the thread here with no reply:
https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz

I don't have an environment to test the patch, but I don't object to
it per se.  However, I don't really want to move forward completely
blindly as well in the long-term.

As mentioned to Niyas, could it be possible to provide to the
community a buildfarm machine that would be able to test this
environment?  I am not sure what's your status on that.  Perhaps this
is already set up and you are just waiting for the patch to be merged?
--
Michael





Re: [PATCH] Add native windows on arm64 support

2023-08-17 Thread Anthony Roberts

Hi All,

Just following up on this, has there been any movement?

I did see another message go into the thread here with no reply: 
https://www.postgresql.org/message-id/ZKPLjLjIjwN2lxkg%40paquier.xyz


Thanks,
Anthony

On 14/06/2023 13:25, Niyas Sait wrote:

Hello,

Just wanted to give a heads up that I am moving to a new role outside 
Linaro and as a result wouldn't be able to continue contributing.


Anthony Roberts from Linaro is going to support the enablement work.