Re: [PATCH] Fix build on MINGW on ARM64

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

In response to

Responses

Browse pgsql-hackers by date

  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