pyconfig.h and freebsd10: _POSIX_C_SOURCE and _XOPEN_SOURCE

[David Chisnall]

On 22 Jan 2012, at 19:25, David Schultz wrote:

> On Sat, Jan 21, 2012, Andriy Gapon wrote:
>> 
>> It seems that python27's pyconfig.h (artificially?) limits visibility of system
>> APIs by setting _POSIX_C_SOURCE to 200112L and _XOPEN_SOURCE to 600.
>> This might not actually change much for earlier FreeBSD versions.
>> 
>> But in FreeBSD 10 we now have interfaces from POSIX 200809, specifically some
>> things that are then used by xlocale.h.
>> 
>> Now take an example of py-lxml port.  It depends on both libxslt and python
>> (obviously).  libxslt doesn't have any limitations in POSIX interfaces that it
>> uses, so it detects xlocale.h and uses it.  xlocale.h depends on definition of
>> locale_t in locale.h.  But since locale_t has been introduced in POSIX 2008 its
>> declaration is under __POSIX_VISIBLE >= 200809.  And because of pyconfig.h,
>> py-lxml build doesn't see locale_t and so the build fails.
>> 
>> This is probably an issue that the upstream should also consider.
>> 
>> Having briefly looked at python27's configure script I wonder if we should set
>> define_xopen_source=no for FreeBSD 10 (like it has been done for FreeBSD/4.*).
>> 
>> But in general I am not sure why python has to limit itself to those levels of
>> interfaces (_POSIX_C_SOURCE 200112L and _XOPEN_SOURCE 600).
>> 
>> Thoughts, ideas, suggestions?
>> Thank you!
> 
> Technically it's a problem with python.  If you ask for a strict
> POSIX environment (doesn't matter what version) and also #include
> a non-POSIX header, there's no guarantee about what you'll get.
> I've CC'd the xlocale author in case he wants to comment or
> voluntarily make xlocale work in an otherwise strict POSIX
> environment, but that's not officially supported.

The problem is really with glibc, which uses these macros in the opposite way to everyone else (glibc thinks defining these macros means expose functionality from this standard, don't expose it otherwise, everyone else thinks they mean expose only the things defined by this standard).  This makes writing portable code a pain and, while I'd usually be keen to blame Python for everything, in this case I sympathise with their problem.  

Would defining locale_t and the related functions in xlocale.h if we are in a mode where they are not normally exposed fix the problem?  

David