I wrote:
> But having said that, it seems there's something wrong with the
> STATIC_IF_INLINE patch for the case where USE_INLINE doesn't get set.
> I'm too tired to investigate right now, but if you manually disable
> USE_INLINE in pg_config.h after configuring, do you see a problem?
I summoned the energy to run a build with an old non-inline-aware
C compiler, and it went through, so the explanation is not that
simple.
Looking again at the spoonbill failure, it's striking that it gets as
far as plpython before choking. The symptoms are consistent with the
theory that USE_INLINE is getting #define'd by some Python header or
other, after having *not* been defined by pg_config.h. Maybe we should
rename that to PG_USE_INLINE?
BTW, just noticing that this theory espoused in plpython.h:
* Undefine some things that get (re)defined in the Python headers. They aren't
* used by the PL/Python code, and all PostgreSQL headers should be included
* earlier, so this should be pretty safe.
is entirely full of it, as the plpy_*.h files feel free to pull in
random Postgres header files. Maybe that area needs another look.
It's (probably) not contributing to this particular breakage, but I
can't say that I think undef'ing things like _POSIX_C_SOURCE midstream
is a bright idea at all. Seems to me that could easily result in
inconsistent results from reading different system header files.
regards, tom lane