Re: [PATCH] Fix build on MINGW on ARM64
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCH] Fix build on MINGW on ARM64 |
Дата | |
Msg-id | 4240b95b-b2e7-4db4-9174-77c2d8496170@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCH] Fix build on MINGW on ARM64 (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: [PATCH] Fix build on MINGW on ARM64
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: