On Tue, 14 Jan 2025 at 12:32, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robins Tharakan <thara...@gmail.com> writes: > > The error seems to be around "annobin.so" and so it may be about how > > gcc is being compiled (not sure). While I figure out if GCC compilation > > needs work, I thought to bring it up here since v16+ seems to work fine > on > > the same box and we may want to consider doing something similar for all > > older versions too? > > This went into v16 and was not back-patched, which is probably wise > because there was at least one followup fix (1c3aa5450) and we still > didn't entirely understand what was happening in the Cygwin build [1]. > So I'm hesitant to consider back-patching it just because your > experimental gcc isn't working.
Thanks for that background. My goal here was to bring up a use-case where we may want to backpatch, but given that there are more moving parts and a backpatch isn't trivial, I also agree that it may not be worth the risk. Especially given that the scenario is rare (i.e. not many people would be hand-compiling gcc to step onto this issue). I've paused parula for now and will re-enable older branches once it is working properly, or, I'll revert to stock gcc as a last resort. > At the very least we ought to find > out why it worked up till three weeks ago. > +1. I'll try to see if GCC is to blame (basically if a gcc commit did this). If that isn't it, another suspect is that since Nov 24, I enabled automatic updates on the box (I used to apply OS updates manually every few months), and an automatic update messed things up in some way (unsure). - robins
