Date: Wed, 25 Jan 2012 13:23:22 +0000 From: David Chisnall <theraven@FreeBSD.ORG> To: David Schultz <das@FreeBSD.ORG> Cc: freebsd-standards@FreeBSD.ORG, python@FreeBSD.ORG, Andriy Gapon <avg@FreeBSD.ORG>, gogo@cs.uni-sb.de Subject: Re: pyconfig.h and freebsd10: _POSIX_C_SOURCE and _XOPEN_SOURCE Message-ID: <9F9CC3ED-0686-4BC5-BF01-1839A30ABA9C@FreeBSD.ORG> In-Reply-To: <20120122192526.GA52071@zim.MIT.EDU> References: <4F1AAA75.5050500@FreeBSD.org> <20120122192526.GA52071@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Jan 2012, at 19:25, David Schultz wrote: > On Sat, Jan 21, 2012, Andriy Gapon wrote: >>=20 >> 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. >>=20 >> But in FreeBSD 10 we now have interfaces from POSIX 200809, = specifically some >> things that are then used by xlocale.h. >>=20 >> 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 >=3D 200809. And because of = pyconfig.h, >> py-lxml build doesn't see locale_t and so the build fails. >>=20 >> This is probably an issue that the upstream should also consider. >>=20 >> Having briefly looked at python27's configure script I wonder if we = should set >> define_xopen_source=3Dno for FreeBSD 10 (like it has been done for = FreeBSD/4.*). >>=20 >> 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). >>=20 >> Thoughts, ideas, suggestions? >> Thank you! >=20 > 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. =20 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? =20 David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9F9CC3ED-0686-4BC5-BF01-1839A30ABA9C>