Thread: Compile 14.1 in EL5.8

Gabriela Serventi <gabrielaserventi@gmail.com> writes:
> Hi! I'm trying to compile release 14.1 in a very old Linux Server (Red Hat
> Enterprise Linux Server release 5.8). I can run configure successfully, but
> when I try to run make, I get the following error:
> latch.c:85:26: error: sys/signalfd.h: No such file or directory

It looks like since 6a2a70a02, latch.c effectively uses HAVE_SYS_EPOLL_H
to decide whether it can include <sys/signalfd.h>, which seems not too
well thought out.  A proper fix will require another configure check,
but you could hack it by adding -DWAIT_USE_POLL to CPPFLAGS in
src/Makefile.global after running configure.

FWIW, EL5 is *ancient*.  You really oughta consider an update.

            regards, tom lane

On Thu, Feb 10, 2022 at 3:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Gabriela Serventi <gabrielaserventi@gmail.com> writes:
> > Hi! I'm trying to compile release 14.1 in a very old Linux Server (Red Hat
> > Enterprise Linux Server release 5.8). I can run configure successfully, but
> > when I try to run make, I get the following error:
> > latch.c:85:26: error: sys/signalfd.h: No such file or directory
>
> It looks like since 6a2a70a02, latch.c effectively uses HAVE_SYS_EPOLL_H
> to decide whether it can include <sys/signalfd.h>, which seems not too
> well thought out.  A proper fix will require another configure check,
> but you could hack it by adding -DWAIT_USE_POLL to CPPFLAGS in
> src/Makefile.global after running configure.

I mean, I did think about it, but I thought it wasn't worth the
configure cycles to detect EOL'd kernels manufactured 2005-2007, since
we've said before that we don't support RHEL5 or kernels that old[1].
My primary goal was not to have to write the support for the
epoll/self-pipe combination with zero coverage and zero users.
Apparently I was off by one on the users, and since it's so easy to
fall back to poll() I agree that we might as well!  BTW after seeing
your commit today I wondered about also removing the leftover comment
"We assume that any system that has Linux epoll() also has Linux
signalfd()" which was my attempt to explain that there wasn't a
separate configure check for signalfd.h, but I guess the sentence is
still true in a more general sense, so we can just leave it there.

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGKL_%3DaO%3Dr30N%3Ds9VoDgTqHpRSzePRbA9dkYO7snc7HsxA%40mail.gmail.com

Thomas Munro <thomas.munro@gmail.com> writes:
> ... I wondered about also removing the leftover comment
> "We assume that any system that has Linux epoll() also has Linux
> signalfd()" which was my attempt to explain that there wasn't a
> separate configure check for signalfd.h, but I guess the sentence is
> still true in a more general sense, so we can just leave it there.

Oh, I didn't notice that comment, or I probably would have tweaked it.
Perhaps along the line of "there are too few systems that have epoll
and not signalfd to justify maintaining a separate code path"?

            regards, tom lane

On Thu, Feb 10, 2022 at 2:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > ... I wondered about also removing the leftover comment
> > "We assume that any system that has Linux epoll() also has Linux
> > signalfd()" which was my attempt to explain that there wasn't a
> > separate configure check for signalfd.h, but I guess the sentence is
> > still true in a more general sense, so we can just leave it there.
>
> Oh, I didn't notice that comment, or I probably would have tweaked it.
> Perhaps along the line of "there are too few systems that have epoll
> and not signalfd to justify maintaining a separate code path"?

WFM, though I remain a little unclear on whether our support policy is
stochastic or declarative :-D