Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE' - Mailing list pgsql-bugs
From | Andres Freund |
---|---|
Subject | Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE' |
Date | |
Msg-id | 20190817224142.gq57z3cwt7c76dtk@alap3.anarazel.de Whole thread Raw |
In response to | Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE' (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE'
Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE' Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier 'FD_SETSIZE' |
List | pgsql-bugs |
Hi, Heh, just discovered https://www.postgresql.org/message-id/20160921171819.1357.29774%40wrigleys.postgresql.org from the same reporter, where we went through this before :/ On 2019-08-17 17:59:05 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2019-08-17 16:31:01 -0400, Tom Lane wrote: > >> PG Bug reporting form <noreply@postgresql.org> writes: > >>> vacuumdb.c:184:26: error: use of undeclared identifier 'FD_SETSIZE' > > >> Hmm, it seems somebody removed the "#include <sys/select.h>" from > >> that file, which was a pretty not-bright idea. > > > Most of the parallel code was move into bin/scripts/scripts_parallel.c - > > but there's still the above error check. Seems like we ought to add a > > ParallelSlotsMax() or such, and use that in the error check, rather than > > check FD_SETSIZE directly? > > Yeah, that would likely be cleaner than just responding to this directly. I'll go and do that. > >> But I wonder why the OpenBSD machines in the buildfarm aren't complaining. > > > Or even why it works on other platforms. > > Indeed. I've confirmed the bug report on a local OpenBSD 6.4 build > (clang 6.0.0), and with "make -k" I can see that reindexdb.c fails > likewise. But this is unsurprising given that POSIX says that > FD_SETSIZE is declared by sys/select.h. Right. > And I'm not that astonished by it not failing on Linux, either; the > glibc headers are well known for #including much more than POSIX says > they must. But it's surprising and worrisome that none of our other > buildfarm platforms complained. Seems like somebody should start > running an animal with a more modern OpenBSD, at least. I don't see an easy option for making glibc less aggressive on that front, unfortunately. And I don't want to start running a vm with openbsd or such. I wonder if it'd be worth setting up a buildfarm animal on linux using musl as the libc, based on a quick look it includes less. Doesn't appear to find this issue however [1], so it's perhaps not worth it. It fails with src/bin/pg_upgrade/file.c including linux/fs.h without a proper configure check: #ifdef __linux__ #include <sys/ioctl.h> #include <linux/fs.h> #endif Probably worth fixing, even if it can also fixed by just symlinking /usr/include/linux into /usr/include/x86_64-linux-musl/ (or whatever is appropriate for the current platform). [1] The relevant commit's explanation isn't very helpful: commit 2555fe1b6da21119f87d407ef3838648d5fd601d Author: Rich Felker <dalias@aerifal.cx> Date: 2011-04-10 22:47:43 -0400 add some ugly legacy type names in sys/types.h (u_char etc.) diff --git a/include/sys/types.h b/include/sys/types.h index 216574ad..5c6b2090 100644 --- a/include/sys/types.h +++ b/include/sys/types.h @@ -59,6 +59,14 @@ extern "C" { #ifdef _GNU_SOURCE typedef unsigned long caddr_t; +typedef unsigned char u_char; +typedef unsigned short u_short, ushort; +typedef unsigned u_int, uint; +typedef unsigned long u_long, ulong; +typedef long long quad_t; +typedef unsigned long long u_quad_t; +#include <endian.h> +#include <sys/select.h> #include <sys/sysmacros.h> #endif Greetings, Andres Freund
pgsql-bugs by date: