Issue14498
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Unsupported provider
Created on 2012-04-04 20:49 by Matthew.Scott, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (5) | |||
---|---|---|---|
msg157504 - (view) | Author: Matthew Scott (Matthew.Scott) | Date: 2012-04-04 20:49 | |
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. > for version in 2.6 2.7 3.2 3.3; do python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.7-intel 2.7.1 macosx-10.7-intel 3.2.2 macosx-10.6-intel 3.3.0a2 macosx-10.6-intel 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 Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk Please check your Xcode installation gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DHAVE_RL_CALLBACK -DHAVE_RL_CATCH_SIGNAL -DHAVE_RL_COMPLETION_APPEND_CHARACTER -DHAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK -DHAVE_RL_COMPLETION_MATCHES -DHAVE_RL_COMPLETION_SUPPRESS_APPEND -DHAVE_RL_PRE_INPUT_HOOK -I. -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c Modules/3.x/readline.c -o build/temp.macosx-10.6-intel-3.2/Modules/3.x/readline.o -Wno-strict-prototypes -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 In file included from Modules/3.x/readline.c:8: /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:11:20: error: limits.h: No such file or directory |
|||
msg157505 - (view) | Author: Matthew Scott (Matthew.Scott) | Date: 2012-04-04 21:02 | |
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: In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET'] Out[1]: '10.6' Using Python 2.7.1: In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET'] Out[1]: '10.7' 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. |
|||
msg157507 - (view) | Author: Matthew Scott (Matthew.Scott) | Date: 2012-04-04 21:10 | |
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 version in 2.6 2.7 3.2 3.3; do MACOSX_DEPLOYMENT_TARGET=10.42 python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.42-intel 2.7.1 macosx-10.42-intel 3.2.2 macosx-10.6-intel 3.3.0a2 macosx-10.6-intel |
|||
msg157509 - (view) | Author: Ned Deily (ned.deily) * | Date: 2012-04-04 21:50 | |
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 |
|||
msg157512 - (view) | Author: Ned Deily (ned.deily) * | Date: 2012-04-04 22:03 | |
BTW, Issue14499 is now open to track the Xcode 4.3 SDK problem. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:28 | admin | set | github: 58703 |
2012-04-04 22:03:40 | ned.deily | set | messages: + msg157512 |
2012-04-04 21:50:50 | ned.deily | set | status: open -> closed nosy: + ned.deily messages: + msg157509 resolution: rejected stage: resolved |
2012-04-04 21:10:30 | Matthew.Scott | set | messages: + msg157507 |
2012-04-04 21:02:15 | Matthew.Scott | set | messages: + msg157505 |
2012-04-04 20:49:28 | Matthew.Scott | create |