Tom Lane 751f532b97 Try another way to detect the result type of strerror_r(). ... The method we've traditionally used, of redeclaring strerror_r() to see if the compiler complains of inconsistent declarations, turns out not to work reliably because some compilers only report a warning, not an error. Amazingly, this has gone undetected for years, even though it certainly breaks our detection of whether strerror_r succeeded. Let's instead test whether the compiler will take the result of strerror_r() as a switch() argument. It's possible this won't work universally either, but it's the best idea I could come up with on the spur of the moment. We should probably back-patch this once the dust settles, but first let's see what the buildfarm thinks of it. Discussion: https://postgr.es/m/10877.1537993279@sss.pgh.pa.us		2018-09-26 18:23:13 -04:00
..
ac_func_accept_argtypes.m4
ax_prog_perl_modules.m4
ax_pthread.m4
c-compiler.m4	Always use our own versions of *printf().	2018-09-26 13:13:57 -04:00
c-library.m4	Try another way to detect the result type of strerror_r().	2018-09-26 18:23:13 -04:00
config.guess	Update config.guess and config.sub	2018-06-11 08:54:58 -04:00
config.sub	Update config.guess and config.sub	2018-06-11 08:54:58 -04:00
docbook.m4
general.m4
install-sh
libtool.m4
llvm.m4	Detect LLVM 7 without specifying binaries explicitly.	2018-09-13 10:42:11 -07:00
Makefile
missing
perl.m4
pkg.m4
prep_buildtree
programs.m4
python.m4
tcl.m4	Make some fixes to allow building Postgres on macOS 10.14 ("Mojave").	2018-09-25 13:23:29 -04:00