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
-std=c++11 flag added on wrong macOS versions #4683
Comments
You are correct. Could you send us a PR for that? |
I am not a Python programmer and don't know how to do a version comparison there. I have also never looked at protobuf code before and don't know what the fix should be. Should the flag be added on 10.12 or later, as it was written? Or should it be 10.9 or later? What will be done for the 3.6.x branch, where as I understand it C++11 will be unconditionally required? |
Yeah, I think we should unconditionally add the flag now. |
Please reopen. That commit only changed master. What about the 3.5.x branch which, if I understand correctly, is intended not to require C++11 yet? |
Although we didn't enforce c++11 in 3.5.x, it can still work with c++11. |
Could you update to our latest release? |
Besides, we do you need our setup.py? Doesn't pypi install work? |
To explain, I am a developer with the MacPorts package management system, where we have ports for protobuf and its python library. Investigating a build failure of that python library port in MacPorts is what led me to report this bug to you.
Right. But you're adding the
Now that you've released 3.6.0, sure, we'll try to update MacPorts to that version. But in the 3.6.0 release notes it says you'll try to keep the 3.5.x branch updated with critical fixes, so hopefully you can still fix this problem in the 3.5.x branch for the next 3.5.x release.
MacPorts runs setup.py when building python libraries. Having MacPorts run another package manager like pypi is problematic so we don't do that. |
I'll fix it. |
I think only commit to 3.5.x is needed, right? There is no need to push packages to pypi |
@TeBoring Hi, it seems that the recently added Mac wheel is still not installing the cpp extensions:
and passing the
So, the issue is coming from changes to the C API in Python 3.7 as described in #4086 Waiting for a fix release that includes the merged results. |
This seems like it may be fixed already -- please reopen if it is not. |
python/setup.py checks the macOS version incorrectly, performing a floating point comparison instead of a version number comparison:
So the
-std=c++11
flag will be added for macOS versions with a floating point value greater than or equal to 10.12—e.g. 10.12, 10.13, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9—but not for 10.10 or 10.11. Surely this isn't what was intended. The clang++ compiler in Xcode on macOS only started using libc++ (which supports C++11) as of 10.9, and newer versions of clang++ in newer versions of Xcode on newer versions of macOS support more of the standard. In 10.8 and earlier, the C++ compilers used libstdc++ 4.2.1 or earlier (which doesn't support C++11 at all).This problem was introduced in the 3.2.x branch in 117f771 and merged to master as part of 7f3e237.
What was the intention? On which macOS versions did you mean to add the flag?
I suspect it is incorrect to add the flag on the basis of a macOS version. You should instead add the flag on the basis of compiler capability. (It is possible to use newer clang++ compilers and libc++ on older versions of macOS and thus give them C++11 capability.)
The text was updated successfully, but these errors were encountered: