pyconfig.h and freebsd10: _POSIX_C_SOURCE and _XOPEN_SOURCE

Tijl Coosemans tijl at
Fri Jan 27 16:09:59 UTC 2012

On Sunday 22 January 2012 20:25:26 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 POSIX feature macros only mean that headers that are part of the
standard need to behave as defined by the standard. Non-standard
headers like xlocale.h can do whatever they want. So if that header
wants to expose a new locale API it can do so, but then it must also
expose locale_t of course, because you cannot use the API without it.

However, xlocale.h is a very ugly header (does different things
depending on which headers have been included already), and some of the
function prototypes have become part of the latest POSIX standard and
need to be moved to different headers (strxfrm_l, strcoll_l,...). So it
may be better to move all prototypes to their respective headers and
remove xlocale.h (or leave a minimal header like glibc seems to have
done). Then libxslt would have to be patched to support plain POSIX and
not require xlocale.h.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
Url :

More information about the freebsd-standards mailing list