[Bug 208486] lang/python27 lang/python33 lang/python34 lang/python35:

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Apr 3 17:49:45 UTC 2016


            Bug ID: 208486
           Summary: lang/python27 lang/python33 lang/python34
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: python at FreeBSD.org
          Reporter: dim at FreeBSD.org
          Assignee: python at FreeBSD.org
             Flags: maintainer-feedback?(python at FreeBSD.org)

Created attachment 168932
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168932&action=edit
Fix python issue 10910 for lang/python[27,33,34,35]

During the exp-run in bug 208158, it was found that pyport.h (from the various
lang/python ports) result in compilation errors with libc++ 3.8.0 [1], for
instance with science/py-scipy:

In file included from scipy/interpolate/src/_interpolate.cpp:4:
In file included from scipy/interpolate/src/interpolate.h:3:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
/usr/include/c++/v1/__locale:468:15: error: C++ requires a type specifier for
all declarations
    char_type toupper(char_type __c) const
/usr/local/include/python2.7/pyport.h:731:29: note: expanded from macro
#define toupper(c) towupper(btowc(c))

This is because pyport.h contains a rather nasty workaround for very old
FreeBSD ctype issue, which was added in August 2004 [2]:

/* On 4.4BSD-descendants, ctype functions serves the whole range of
 * wchar_t character set rather than single byte code points only.
 * This characteristic can break some operations of string object
 * including str.upper() and str.split() on UTF-8 locales.  This
 * workaround was provided by Tim Robbins of FreeBSD project.

#ifdef __FreeBSD__
#include <osreldate.h>
#if __FreeBSD_version > 500039

#if defined(__APPLE__)

#include <ctype.h>
#include <wctype.h>
#undef isalnum
#define isalnum(c) iswalnum(btowc(c))
#undef isalpha
#define isalpha(c) iswalpha(btowc(c))
#undef islower
#define islower(c) iswlower(btowc(c))
#undef isspace
#define isspace(c) iswspace(btowc(c))
#undef isupper
#define isupper(c) iswupper(btowc(c))
#undef tolower
#define tolower(c) towlower(btowc(c))
#undef toupper
#define toupper(c) towupper(btowc(c))

Re-defining the macros like this causes trouble with some standard C++
libraries, which explicitly undefine such macros, and create them as inline
functions instead.  This problem was already reported to upstream Python in
2011, as issue 10910 [3].

The approach there is to wrap the workaround in an #ifdef __cplusplus, but
after some digging, I found out that the original bug in ctype, which for
example gave back 'True' for isspace('\xa0'), has already been solved in
October 2007 by Andrey Chernov, in r172619 [4].  The ctype fixes were MFC'd to
stable/6 and stable/7 in r172929 [5].

I propose to add the attached patch to lang/python[27,33,34,35], which instead
corrects the __FreeBSD_version check to the following:

#if (__FreeBSD_version >= 500040 && __FreeBSD_version < 602113) || \
    (__FreeBSD_version >= 700000 && __FreeBSD_version < 700054) || \
    (__FreeBSD_version >= 800000 && __FreeBSD_version < 800001)

Alternatively, since we don't really support such old FreeBSD versions anymore,
the whole check and workaround can be removed instead.  However, I also
submitted the same change to upstream Python, in issue 10910, so hopefully this
fix will appear in future Python releases.

[2] https://hg.python.org/cpython/rev/adfe7d39a049
[3] http://bugs.python.org/issue10910
[4] https://svnweb.freebsd.org/base?view=revision&revision=172619
[5] https://svnweb.freebsd.org/base?view=revision&revision=172929

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-python mailing list