Re: [PATCH] Fix build on MINGW on ARM64
От | vignesh C |
---|---|
Тема | Re: [PATCH] Fix build on MINGW on ARM64 |
Дата | |
Msg-id | CALDaNm2b+QVTpnAQvPZS0ru_6Mua1OEV8iWK8zwUVt9N+4UWQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Fix build on MINGW on ARM64 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: [PATCH] Fix build on MINGW on ARM64
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: