[PATCH] Fix build on MINGW on ARM64
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.
--
Regards, Lars
Attachments:
0001-Use-workaround-of-__builtin_setjmp-only-on-MINGW-on-.patchapplication/octet-stream; name=0001-Use-workaround-of-__builtin_setjmp-only-on-MINGW-on-.patchDownload+5-6
On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars@greiz-reinsdorf.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.patchIt is also used in ruby-pg to allow compiling for
aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/filesIt 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]https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32.
[1]: https://stackoverflow.com/questions/53709069/setjmp-longjmp-in-x86-64-w64-mingw32
Regards,
Vignesh
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars@greiz-reinsdorf.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.patchIt is also used in ruby-pg to allow compiling for
aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/filesIt 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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan <andrew@dunslane.net> wrote:
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars@greiz-reinsdorf.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.patchIt is also used in ruby-pg to allow compiling for
aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/filesIt 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-mingw32That 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]https://commitfest.postgresql.org/patch/5610/. 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
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan <andrew@dunslane.net> wrote:
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars@greiz-reinsdorf.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.patchIt is also used in ruby-pg to allow compiling for
aarch64-w64-windows-gnu: https://github.com/ged/ruby-pg/pull/626/filesIt 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-mingw32That 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
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
On Tue, 1 Apr 2025 at 16:02, Andrew Dunstan <andrew@dunslane.net> wrote:
On 2025-04-01 Tu 5:16 AM, vignesh C wrote:
On Sun, 2 Feb 2025 at 00:52, Lars Kanis <lars@greiz-reinsdorf.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.patchIt is also used in ruby-pg to allow compiling for
aarch64-w64-windows-gnu:
https://github.com/ged/ruby-pg/pull/626/filesIt 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-mingw32That 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.
Done
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
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.
Done
fairywren has been failing rather horribly since this went in [1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-04-02%2007%3A06%3A04.
It's not certain of course that this commit broke it and not one
of the other ones that first appeared in that build -- but none
of the other ones look plausibly related.
regards, tom lane
[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-04-02%2007%3A06%3A04
On 2025-04-07 Mo 12:58 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
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.
Done
fairywren has been failing rather horribly since this went in [1].
It's not certain of course that this commit broke it and not one
of the other ones that first appeared in that build -- but none
of the other ones look plausibly related.regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-04-02%2007%3A06%3A04
Yes, that was indeed the problem. I have reverted the patch.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-04-07 Mo 11:05 AM, Andrew Dunstan wrote:
On 2025-04-07 Mo 12:58 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 2025-04-01 Tu 11:15 AM, Andrew Dunstan wrote:
On 2025-04-01 Tu 8:47 AM, vignesh C wrote:
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.
Done
fairywren has been failing rather horribly since this went in [1].
It's not certain of course that this commit broke it and not one
of the other ones that first appeared in that build -- but none
of the other ones look plausibly related.regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-04-02%2007%3A06%3A04Yes, that was indeed the problem. I have reverted the patch.
Lars,
I have marked the CF entry as Returned with Feedback - you can submit
again, but will need to show that this does not cause breakage on x86_64
using any msys2 toolchain.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com