The version of this macro used in autoconf 2.59 is capable of incorrectly
succeeding (ie, reporting that a library function is available when it
isn't), if the compiler performs link-time optimization and decides that
it can optimize the function reference away entirely. Replace it with the
coding used in autoconf 2.61 and later, which forces the program result to
depend on the function's result so that it cannot be optimized away. This
should fix build failures currently being seen on buildfarm member anchovy.
This patch affects the 8.2 and 8.3 branches only, since later branches are
using autoconf versions that don't have this problem.
We previously found out that OS X's standard perl installation tries to put
-arch switches into Perl link commands, evidently in hopes of building
universal binaries. But it doesn't work to add such switches in plperl's
link step if they weren't being used earlier, so this is basically
unworkable. When using gcc the result is only some warnings; but LLVM
fails entirely, so this issue isn't as cosmetic as we originally thought.
Hence, back-patch commit d69a419e68 into
pre-9.0 branches.
Apparently there is no buildfarm critter exercising this case after all,
because it fails in several places. With this patch, build, install,
check-world, and installcheck-world pass for me on OS X.
code relies on the checking macro actually being called at the end, or the
automatic undiversion will produce garbage. These sort of implicit
side-effects undermine the modularity of the macros and happen to break the
ODBC driver which makes use of them.
Also put the warnings at the very end of configure, so there is an even
better chance of seeing them.
+ # Determine if printf supports %1$ argument selection, e.g. %5$ selects
+ # the fifth argument after the printf print string.
+ # This is not in the C99 standard, but in the Single Unix Specification (SUS).
+ # It is used in our langauge translation strings.
Nicolai Tufar with configure changes by Bruce.
reliably (ie, regardless of which libraries they depend on). Also
make sure that we don't select headers that obviously belong to the
wrong one of the two libraries. This was discussed back around 4-Sep
but seems to have slipped through the cracks. The header selection
could be checked more closely, perhaps, but let's see if this is good
enough.
compiler emits any warnings, the test program had better be 100%
correct, not only 90% correct. The recent addition of -Wold-style-definition
broke thread-safety detection on every platform that has that switch,
because the test program used an old-style definition.
-O2 -Wall -Wmissing-prototypes -Wpointer-arith
Check whether the version of GCC we are using supports any of:
-Wdeclaration-after-statement
-Wendif-labels
-Wold-style-definition
And add the supported flags to CFLAGS.
-L spec rather than assuming libpython is in the standard search path
(this returns to the way 7.4 did it). But check the distutils output
to see if it looks like Python has built a shared library, and if so
link with that instead of the probably-not-shared library found in
configdir.
Tom Lane