I wrote:
> Here's a revised patch that I've tested (albeit lightly) on
> both HPUX and Solaris.
Hm, I'd verified the configure results, but I didn't wait around
for the builds to finish, which was a mistake. On Solaris 11:
command.c: In function 'do_watch':
command.c:5062:8: error: too many arguments to function 'sigwait'
if (sigwait(&sigalrm_sigchld_sigint, &signal_received) < 0)
^
In file included from ../../../src/include/fe_utils/print.h:16:0,
from command.h:12,
from command.c:28:
/usr/include/signal.h:233:12: note: declared here
extern int sigwait(sigset_t *);
^
gmake[3]: *** [<builtin>: command.o] Error 1
gmake[2]: *** [Makefile:43: all-psql-recurse] Error 2
gmake[1]: *** [Makefile:42: all-bin-recurse] Error 2
gmake: *** [GNUmakefile:11: all-src-recurse] Error 2
What is happening is obvious in retrospect. Per my patch, configure
checks how sigwait is declared with -D_POSIX_PTHREAD_SEMANTICS, and
that's also how libpq's reference is compiled ... but psql's reference
is not compiled that way. It seems to work if we force command.c
to be compiled with PTHREAD_CFLAGS added, but that is really quite
grotty. I think it'd be safer to push the sigwait reference out
into a separate file to minimize the scope of those flags.
Just how badly did you want to use sigwait here? I'm having
considerable second thoughts about the value of that change
versus the hoops we're going to have to jump through to use it.
(I suppose a hacky solution might be to never define USE_SIGWAIT
on Solaris.)
regards, tom lane
