mirror of
https://github.com/postgres/postgres.git
synced 2025-05-12 16:21:30 +03:00
a65e086453
Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2 (POSIX 1997), which we generally consider to define our minimum required set of Unix APIs. Moreover, no buildfarm member has reported not having them since 2012 or before, which means that even if the code is still live somewhere, it's untested --- and we've made plenty of signal-handling changes of late. So just take these APIs as given and save the cycles for configure probes for them. However, we can't remove as much C code as I'd hoped, because the Windows port evidently still uses the non-POSIX code paths for signal masking. Since we're largely emulating these BSD-style APIs for Windows anyway, it might be a good thing to switch over to POSIX-like notation and thereby remove a few more #ifdefs. But I'm not in a position to code or test that. In the meantime, we can at least make things a bit more transparent by testing for WIN32 explicitly in these places.
src/port/README
libpgport
=========
libpgport must have special behavior. It supplies functions to both
libraries and applications. However, there are two complexities:
1) Libraries need to use object files that are compiled with exactly
the same flags as the library. libpgport might not use the same flags,
so it is necessary to recompile the object files for individual
libraries. This is done by removing -lpgport from the link line:
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
and adding infrastructure to recompile the object files:
OBJS= execute.o typename.o descriptor.o data.o error.o prepare.o memory.o \
connect.o misc.o path.o exec.o \
$(filter snprintf.o, $(LIBOBJS))
The problem is that there is no testing of which object files need to be
added, but missing functions usually show up when linking user
applications.
2) For applications, we use -lpgport before -lpq, so the static files
from libpgport are linked first. This avoids having applications
dependent on symbols that are _used_ by libpq, but not intended to be
exported by libpq. libpq's libpgport usage changes over time, so such a
dependency is a problem. Win32, Linux, and Darwin use an export list to
control the symbols exported by libpq.