From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
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 15:15:34 |
Message-ID: | 91e3ec76-ac83-4c6b-8bec-3c7c346b4c8d@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
> 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/
>
Somehow I missed that. OK, looks good, will commit shortly.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-04-01 15:15:52 | Re: Fix 035_standby_logical_decoding.pl race conditions |
Previous Message | Bertrand Drouvot | 2025-04-01 15:13:27 | Re: Draft for basic NUMA observability |