On 07/25/2011 12:03 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net> writes:
>> On 07/25/2011 10:52 AM, Tom Lane wrote:
>>> What is features.h, and have its authors read the POSIX standard?
>>> AFAICS they have no business defining this symbol.
>> [andrew@emma ~]$ rpm -q -f /usr/include/features.h
>> glibc-headers-2.13-1.x86_64
> Oh, for some reason I was thinking this was mingw-specific.
>
> [ pokes around ... ] I still think it's a bad idea for the header
> files to be defining this, but they'll probably point at the part
> of the POSIX spec that says the results are undefined if the macro
> is changed after the first system header is #included.
>
> I can't immediately think of any way to actually do what you were
> trying to do (ie, save and restore the definition of the macro).
> I wonder whether it would be good enough to do this:
>
> #include postgres.h
>
> #include everything else we want except python headers
>
> #undef _POSIX_C_SOURCE
> #undef _XOPEN_SOURCE
>
> #include python headers
>
> ... rest of .c file ...
>
> This should only fail if (a) some macro imported from system headers
> attempts to test the value of a feature macro, and (b) the results
> vary between the system default setting and the setting the python
> headers selected. Neither of these things seem very probable.
OK, attached gives a clean build and passes regression on my Windows box
that builds with Python. I had to undefine a few more things and save
and restore our *snprintf settings (with code borrowed from plperl.h,
where we did this sort of cleanup a while ago).
cheers
andrew