-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation #55119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I was recently attempting to get Botan (http://botan.randombit.net) working with Python 2.6.6 on FreeBSD when it failed to compile, I filled a bug with Botan (http://bugs.randombit.net/show_bug.cgi?id=135) and first thought it was a compiler issue, and then thought it might be a Boost.Python issue. However after further digging, see comment 3 (http://bugs.randombit.net/show_bug.cgi?id=135#c3) I figured out it had to do with the fix that went in to pyport.h for issues with isspace/toupper/et al. on FreeBSD's libc and also Mac OS X. As can be seen in http://svn.python.org/view/python/trunk/Include/pyport.h?r1=36519&r2=36793 a change was added to override the original definitions with a new one that used the wide character support. It was modified again in http://svn.python.org/view/python/trunk/Include/pyport.h?r1=77585&r2=80178 to also include Mac OS X for http://bugs.python.org/issue7072. The issue here is that if this file is included in any C++ code that then also includes <locale> or any of other functions that might pull in localefwd.h the defines will cause actual C++ code functions to be overwritten with invalid data, and the C++ compiler will throw errors such as: /usr/include/c++/4.2/bits/localefwd.h:58:34: error: macro "isspace" passed 2 Putting an #if 0, #endif around that block of code allows Botan's python module to cleanly compile without issues. I do apologise that I don't have a simple C++ program that reproduces the problem. |
I'm upgrading from Python 2.6.5 to 2.7.1, and I'm getting the error below when compiling my code using Boost 1.45 and gcc 4.2.1 in OSX 10.6.6. The following thread describes similar symptoms related to the ordering of header files and macro definitions: The suggested patch to pyport.h (http://codereview.appspot.com/179049/patch/1/2) does not fix my problem. However, prepending #include "Python.h" to each source file (e.g., bend.cc below) does fix the problem. Is there a simple way to fix this without adding Python.h to every source file in my codebase? I've installed Boost and Python from source to non-standard directories, Boost 1.45 by: and Python 2.7 by: Any guidance will be greatly appreciated. Kind regards, ===============
...failed darwin.compile.c++ bin/darwin-4.2.1/release/threading-multi/bend.o... |
This doesn't look like it has anything to to with the 'ctypes' library |
Meador et al, Thanks for your attention to this issue. Just to clarify, I can eliminate #include "Python.h" to any source file with #include<boost/python.hpp> Also, my code compiles in Linux, with and without the Python.h header: $ uname -a
Linux nxx.xx.com 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:38:05 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux with the same flags as before: cd cd $(PYTHON_SRCDIR) ; ./configure --enable-shared Thanks again, |
The problem is that pyport tries to replace the ctypes definion of the isascii(ch) and related functions by a replacement that works better with UTF-8 on FreeBSD and OSX. That replacement is incompatible with the localfwd.h header. The attached patch is a very crude hack that should fix the issue for this. This assumes that Python itself won't be compiled with C++ though, and might cause problems in C++ programs that use locale.h instead of localfwd.h. As such I won't apply the patch just yet, the patch needs review from someone that's more experienced w.r.t. C++. |
Ronald, Thanks much for your help and insight. I tried the patch but unfortunately it didn't work for me-- this might be because I have Python extensions written in C++. Any other suggestions? Should I wait for the next version of boost.python? Thanks and regards, |
Waiting for a new version of boost probably won't help: this is an incompatibility between a redefinition of ctypes macros in pyport.h and definitions in the C++ header <locale>. I barely use C++ at this time and don't know how to tweak the headers to avoid this problem. It would probably have been better to not redefine the ctype.h definitions, we should have introduced Py_isascii etc. That requires some invasive changes to the Python codebase though, and I'm not sure if that is worth the trouble. Could someone attach a sample project that suffers from this issue (with instructions on how to build it)? That would make it easier to debug the problem. (Removing python 2.6 because that version receives only security patches at this time, adding 3.2 and 3.3 because those use the same code in pyport.h and hence should also be affected by this issue) |
Ronald, thanks again. I stripped out as much as I could from the The sample project consists of: test-boost-python/Makefile Before building the project (just type "make" in test-boost-python), Thanks and kind regards, |
With attachment-- |
I am experiencing the same issue. Googled for a bit but couldn't find much with the error, then changed the search context, come across to this thread. In file included from /opt/local/include/boost/date_time/gregorian/parsers.hpp:13, |
if I put "#include <cctype>" before boost/date_time, it solves my problem. And by the way, i can't seem to get to the point where boost/week_ptr.hpp causes the error. I tried to compile Nasos's upload test-boost-python. That codes works on my machine. |
Nevermind, putting #include <cctype> doesn't help. I have to put <python.h> on top to get away this. |
The only real fix I found is to introduce "Py_" prefixed versions of all definitions in ctypes.h that are used in Python (that is Py_isalnum) and use that throughout the python source tree. That's a pretty invasive patch though and would probably be off-limit for 2.7 and 3.2. |
In my first comment on this bug post I posted what project has issues with this, Botan with Boost.Python on FreeBSD and Mac OS X. If required I will post how to reproduce this error using that project. If you would prefer a simplified test case, unfortunately I don't have the time to dig into that and find one. One way to solve it is by including the Python header before any other file, however this is not an option for most 3rd party software that never sees this bug because those functions are not redefined for Linux... |
Per Chen Huang's comment, I retested my test case code using several versions of boost and Python 2.7: boost 1.45: build fails, errors as reported. I've attached a revised test case that automatically downloads and builds boost 1.45. |
I'm happy to review patches or create them for you. I see a related set of errors on Mac OS X that are down to issues in bytes_methods.py that mirror the pyport.h issues. In C++ isspace and friends are functions not macros. Here are the lines in python2.7 that cause compilation errors for me. /Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/bytes_methods.h:#undef isspace |
The bytes_methods.h issue is not present in the default branch, but is still present in the 2.7 branch. I'm not sure why those defines are there, I'm adding Gregory P. Smith to the nosy list because he added the defines and might remember why they were added and if it would be save to remove them (from bytes_methods.h). That is defines like this: #undef islower
#define islower(c) undefined_islower(c) I don't know what to do about the defines in pyport.h, one workaround is disable that entire block for C++ compiler, as in the attached patches (the later one is the same as the first one, but adds a comment that explains why the code is disabled for C++) |
I was merely refactoring for PEP-3137, the original version of all that code prior to 2.7 was in Objects/stringobject.c and long predates me. |
I've some more digging to do then, although I expect that nobody knows anymore why the #define's are there. It should be safe to remove them by now, and they are not present in the default branch. |
I am a FreeBSD committer, and I recently ran into this issue too, since I am working on an update of libc++ in the FreeBSD base system. As part of this work, we attempt to recompile all ports with the proposed change (see [1]). During such a recompile, we get many errors in ports that include pyport.h in C++ mode, similar to (see [2]): 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 'toupper'
#define toupper(c) towupper(btowc(c))
^ I think Ronald's proposed workaround is fine, since messing with ctype macros is risky in C++ mode. E.g. the libc++ <ctype.h> header explicitly undefines all ctype macros, and replaces them with inline functions. Additionally, the original issue mentioned in changeset 32950 [3] was fixed in October 2007 for FreeBSD 8.x [4], and subsequently the fix was merged back to FreeBSD 6.x and 7.x [5]. I'm adding an additional diff that corrects the __FreeBSD_version number checks. This will also be submitted to the FreeBSD ports bug tracker. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208158 |
What do you think, Ned? |
@brett / Ned I'm happy to carry the proposed patch in the FreeBSD ports/packages until the next releases if that helps your confidence levels. |
New changeset 2f857ac9c7af by Ned Deily in branch '3.5': New changeset 27a99a722828 by Ned Deily in branch '3.5': New changeset 5ca8790f1161 by Ned Deily in branch 'default': New changeset e0ec3471cb09 by Ned Deily in branch '2.7': New changeset 12a70477db03 by Ned Deily in branch '2.7': |
I have no special insight into this one but, since there seems to be general agreement here that this makes things better for those using C++ on OS X and FreeBSD, I guess it's time to try it. Pushed for release in 2.7.13, 3.5.3, and 3.6.0. Thanks for the version update, Dimitry. BTW, it would be good if you signed the PSF Contributor Agreement (https://www.python.org/psf/contrib/contrib-form/). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: