Thread: Re: BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head
Re: BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head
From
Andres Freund
Date:
Hi, On 2021-03-15 12:12:59 -0400, Tom Lane wrote: > Although I remain worried about this being an ABI break, I don't think > we are locked into it until we get to beta, or maybe even RC stage. Could it make sense to define sigjmp_buf as a union over the potentially needed implementations? That'd allow us to switch back without an ABI break if we discover a problem with the gcc approach. And it might even allow to backpatch this, if we cared enough, since I assume the mingw jmp_buf is larger than intptr_t[5]. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes: > On 2021-03-15 12:12:59 -0400, Tom Lane wrote: >> Although I remain worried about this being an ABI break, I don't think >> we are locked into it until we get to beta, or maybe even RC stage. > Could it make sense to define sigjmp_buf as a union over the potentially > needed implementations? That'd allow us to switch back without an ABI > break if we discover a problem with the gcc approach. No, it'd still be an ABI break, because the setjmp and the longjmp calls have to use the same implementation. Ain't gonna work if elog.c tries to throw via mingw's longjmp() while some extension contains a PG_TRY that uses __builtin_setjmp(). Nor vice versa. regards, tom lane
Re: BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head
From
Andres Freund
Date:
Hi, On 2021-03-19 20:37:17 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2021-03-15 12:12:59 -0400, Tom Lane wrote: > >> Although I remain worried about this being an ABI break, I don't think > >> we are locked into it until we get to beta, or maybe even RC stage. > > > Could it make sense to define sigjmp_buf as a union over the potentially > > needed implementations? That'd allow us to switch back without an ABI > > break if we discover a problem with the gcc approach. > > No, it'd still be an ABI break, because the setjmp and the longjmp calls > have to use the same implementation. Ain't gonna work if elog.c tries > to throw via mingw's longjmp() while some extension contains a PG_TRY > that uses __builtin_setjmp(). Nor vice versa. Yea, I momentarily forgot that we can't easily wrap setjmp in a function... I guess we could just make sigsetjmp set a flag that indicates which longjmp to use, but that's probably more complication than the issue / mingw warrants. - Andres