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]/messages/by-id/CA+hUKGKL_=aO=r30N=s9VoDgTqHpRSzePRbA9dkYO7snc7HsxA@mail.gmail.com.
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]: /messages/by-id/CA+hUKGKL_=aO=r30N=s9VoDgTqHpRSzePRbA9dkYO7snc7HsxA@mail.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