From owner-freebsd-python@FreeBSD.ORG Thu Jan 26 12:42:37 2012 Return-Path: Delivered-To: python@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82E59106567B; Thu, 26 Jan 2012 12:42:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4BB8FC21; Thu, 26 Jan 2012 12:42:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA27737; Thu, 26 Jan 2012 14:42:33 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F214A39.6050403@FreeBSD.org> Date: Thu, 26 Jan 2012 14:42:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Eitan Adler References: <4F1AAA75.5050500@FreeBSD.org> <20120122192526.GA52071@zim.MIT.EDU> <9F9CC3ED-0686-4BC5-BF01-1839A30ABA9C@FreeBSD.ORG> <4F206B5D.3080302@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-standards@FreeBSD.org, David Schultz , David Chisnall , python@FreeBSD.org, gogo@cs.uni-sb.de Subject: Re: pyconfig.h and freebsd10: _POSIX_C_SOURCE and _XOPEN_SOURCE X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:42:37 -0000 on 26/01/2012 06:47 Eitan Adler said the following: > On Wed, Jan 25, 2012 at 3:51 PM, Andriy Gapon 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