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) ? -- Eitan Adler _______________________________________________ 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"
