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
Python 3.x distutils.util.get_platform returns incorrect value using Mac OSX 10.7 #58703
Comments
Using Python 3.2.2 and Python 3.3.0a2 (installed via 64-bit installers in official DMGs on python.org), 'distutils.util.get_platform()' returns an incorrect OS version when running on Mac OSX 10.7. Using Python 2.6.7, and Python 2.7.1 (the versions included with Mac OSX), the output indicates 'macosx-10.7' correctly.
Some packages make use of this in their setup.py to determine the proper location of libraries. For example, the 'readline' distribution's setup.py does so here: https://github.com/ludwigschwardt/python-readline/blob/6f0e801fa1632fcbb0e005eb9709aaa6051a0f28/setup.py#L33 It fails due to the incorrect assumption that it's running on 10.6 instead of 10.7. Excerpt from "python setup.py bdist_egg": building 'readline' extension |
In the cases of both Python 3.x and 2.x, get_platform() is deriving information about the version of OSX from the 'MACOSX_DEPLOYMENT_TARGET' dictionary returned by distutils.sysconfig.get_config_vars(). Using Python 3.2.2: Using Python 2.7.1: While the deployment target seems like a useful source of information, it does not seem to be accurate enough to "Return a string that identifies the current platform" as the docstring for distutils.util.get_platform() suggests. |
Interestingly, the 2.x series allowed an os.environ override for the MACOSX_DEPLOYMENT_TARGET value, while the 3.x series did away with that, as a result of http://bugs.python.org/issue9516
|
For OS X builds, the value returned in get_platform() is not intended to indicate what OS version the Python instance is running on. Rather, it indicates which ABI version was used to build the Python in use so that Distutils can use the same ABI for building C extension modules. The ABI is determined by the value of MACOSX_DEPLOYMENT_TARGET at build time. In this case, a value of "macosx_10.6-intel" means the resulting executables and object files are a universal build with both 32-bit (i386) and 64-bit (x64_64) Intel architectures and can run on Mac OS X 10.6 and higher. The reason the Apple-supplied system Pythons have a value of 10.7 is that they are built with a deployment target of 10.7; they have no need to run on earlier version of OS X. The issue with the readline extension build you cite is the error "Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk". Chances are you are using the most recent Xcode release (4.3.x) from Apple which unfortunately moved the location of the SDKs from /Developer, which now no longer is used by Xcode, to within the Xcode.app bundle itself, now located in /Applications. A workaround for Xcode 4.3 is to install a symlink to the old location: sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer |
BTW, bpo-14499 is now open to track the Xcode 4.3 SDK problem. |
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: