From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Lars Kanis <lars(at)greiz-reinsdorf(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Fix build on MINGW on ARM64 |
Date: | 2025-04-01 12:47:32 |
Message-ID: | CALDaNm2b+QVTpnAQvPZS0ru_6Mua1OEV8iWK8zwUVt9N+4UWQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
> > On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars(at)greiz-reinsdorf(dot)de> wrote:
> >> This patch limits the workaround of using __buildin_setjmp on the
> >> Windows MINGW platform. This workaround is only necessary for legacy
> >> MSVCRT based toolchain, but not for UCRT based. It is not available at
> >> all on clang on ARM64 resulting in the following compiler error:
> >>
> >> error: __builtin_longjmp is not supported for the current target
> >>
> >> This patch is used since years in MSYS2 packages:
> >> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-postgresql/postgresql-14.0-use-mingw-setjmp-on-ucrt.patch
> >>
> >> It is also used in ruby-pg to allow compiling for
> >> aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/files
> >>
> >> It would be nice if this patch could be merged upstream.
> > Are there any known issues with using __builtin_setjmp? I'm asking
> > because the comment mentions about the long standing issues in its
> > setjmp "However, it seems that MinGW-64 has some longstanding issues
> > in its setjmp support, so on that toolchain we cheat and use gcc's
> > builtins. Also few users have reported segfaults when using setjmp
> > with MinGW as in [1].
> > [1] - https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32
> >
>
> That report is from quite a few years ago, so I'm not sure it really helps.
>
> If one of you would add this to the next CF we could see how the CFbot
> reacts to it. In general it looks sane.
There is an existing CF entry for this at [1]. If no one picks this
till the end of this CF, we can move it to next CF.
[1] - https://commitfest.postgresql.org/patch/5610/
Regards,
Vignesh
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2025-04-01 12:50:32 | Re: Using read stream in autoprewarm |
Previous Message | Robert Haas | 2025-04-01 12:32:04 | Re: RFC: Logging plan of the running query |