On Thu, Jul 16, 2020 at 10:48 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > We haven't changed anything, ergo something changed at the OS level. > > Oddly, we'd not get to this code unless configure set > HAVE_DECL_SYS_SIGLIST, so it's defined *somewhere*. I suspect the root > issue here is some rearrangement of system header files combined with > wait_error.c (and maybe other places?) not including exactly the same > headers that configure tested.
It looks like glibc very recently decided[1] to hide the declaration, but we're using a cached configure test result. I guess rawhide is the RH thing that tracks the bleeding edge? > Anyway, rather than installing rawhide and trying to debug this, > I'd like to make a modest proposal: let's back-patch the v12 > patches that made us stop relying on sys_siglist[], viz a73d08319 > and cc92cca43. Per the discussions that led to those patches, > it's been decades since any platform didn't have POSIX-compliant > strsignal(), so we'd be much better off relying on that. Seems sensible. Despite the claims of the glibc manual[2], it's not really a GNU extension, and the BSDs have it (for decades). [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b1ccfc061feee9ce616444ded8e1cd5acf9fa97f [2] https://www.gnu.org/software/libc/manual/html_node/Signal-Messages.html
