Thread: Re: [PATCH] Fix build on MINGW on ARM64
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.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 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.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. 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.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
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.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
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.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. 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]. 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%3A04 > > > > Yes, 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