on 26/01/2012 06:47 Eitan Adler said the following: > On Wed, Jan 25, 2012 at 3:51 PM, Andriy Gapon <a...@freebsd.org> wrote: >> on 25/01/2012 15:23 David Chisnall said the following: >>> On 22 Jan 2012, at 19:25, David Schultz wrote: >>>> 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. >> >> Thank you for the insights. >> >>> 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? >> >> I think that this should work. > > What about patching python to only define the POSIX macros iff glibc > is being used (and getting this upstreamed) ?
IMO, this should work too. At least for us :-) -- Andriy Gapon _______________________________________________ freebsd-python@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
