[issue11485] Default SDK value on MacOSX needs changing

[Ned Deily]

Ned Deily  added the comment:

Update: as of 3.6.5 and 2.7.15 and in the upcoming 3.7.0 release, macSO 
framework builds with --enable-universalsdk=/ no longer add -isysroot=/ to 
compiler and linker calls.  They are not necessary and made it more difficult 
to attempt to override.  Although we still do not officially support building 
on newer macOS systems for older systems (due to lack of "weak link" testing 
support and issues with setup.py and configure), it should now be possible to 
more easily use the Apple build tool chain features documented for xcrun, like 
the DEVELOPER_RUN and SDKROOT environment variables (see 'man xcrun').  This 
includes current python.org macOS installer builds.  So I think we can finally 
close this.  Thanks all!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7 -Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ned Deily]

Ned Deily  added the comment:


New changeset ee8e4b61d6181f5bfadf6ee3d229f0ebda8a6ae9 by Ned Deily in branch 
'2.7':
[2.7] Backport macOS universal build and installer fixes from 3.6. (GH-6469)
https://github.com/python/cpython/commit/ee8e4b61d6181f5bfadf6ee3d229f0ebda8a6ae9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +6167

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ned Deily]

Ned Deily added the comment:

For 3.3.0, ./configure (configure.ac) was modified in 688d48e434e4 for 
Issue13590 to use more appropriate defaults for universal builds on newer 
releases. In particular, --enable-universalsdk=yes uses the Xcode default SDK 
(as returned by xcodebuild) instead of the 10.4u SDK (not included with Xcode 
4), --with-universal-archs now defaults to intel if ppc support is not 
available, and MACOSX_DEPLOYMENT_TARGET defaults to the OS level for 10.6 and 
newer systems (rather than using 10.4 or 10.3 by default). It also attempts to 
avoid building Python with deprecated and problematic Apple llvm-gcc compiler, 
using clang instead.  The defaults can be overridden by providing explicit 
arguments and/or environment variables to ./configure (--enable-universalsdk, 
--with-universal-archs, CC, MACOSX_DEPLOYMENT_TARGET).  While not 100% perfect, 
the 3.3 changes give good defaults for nearly all common universal build 
configurations on 10.4 through 10.8.

2.7.x and 3.2.x have the same problems; attached are patches that backport the 
3.3 configure changes to them.  However, they do introduce a potential 
incompatibility.  Currently, 2.7 and 3.2 initial configures set 
MACOSX_DEPLOYMENT_TARGET by default to 10.4 (10.3 on a PPC system) for 
non-universal builds or 32-bit universal builds and to 10.5 for other universal 
builds.  For 3.3, those values are still used for 10.4 and 10.5 systems; for 
10.6 and later systems, the default deployment target is now the OS level 
itself (10.6 for builds on 10.6, etc).  Changing the default deployment target 
for more recent systems has some benefits: the most obvious is that readline 
support linking with the system BSD libedit is now enabled by default.  The 
potential incompatibility is that the deployment target value is used by 
distutils.util.get_platform() to form the platform name which is used for bdist 
names (like eggs) and the lib build directory for the standard library build.  
While I haven't ve
 rified that this is the case, if you've built Python 2.7.2, say, from source 
on 10.6+ and installed some extension modules with Distutils, then would build 
from a new release with the proposed patches and install to the existing 
install location without reinstalling the extension modules, there might be a 
chance of unexpected incompatibilities between the old extension module (built 
to an older deployment target) and the upgraded interpreter.  Perhaps somewhat 
more likely is that an extension module binary distribution available on PyPI 
was available for the old deployment target (10.4) but not for the new target 
(10.6). Also, it is possible that differences in behavior might be introduced 
by a change in default compiler.  All of these potential incompatibilities can 
be avoided by overriding the changed defaults, either at Python build time with 
arguments to ./configure or at extension module build time with environment 
variables or Distutils config files.  Introducing such changes 
 is clearly acceptable with a new release, such as 3.3.  For existing releases, 
it can be argued that the newer, more appropriate settings can also be obtained 
by just overriding the old defaults (Explicit is better than implicit.).  The 
question then is, when the old default behavior no longer makes sense due to 
changes outside of our control, do the benefits of changing them in a 
maintenance release outweigh the risk of introducing an incompatibility?

If they are applied, some or all of the changes to the Mac/README file should 
be backported as well. Also, while working on this, I did find one edge case 
where the ./configure defaults do not produce a buildable configuration.  The 
case is on 10.6 with (the optional) Xcode 4.  For universal builds, the test 
added early in ./configure to determine if ppc is supported doesn't work.  
Since the correct compiler hasn't been determined yet, the test looks at the 
architectures in /usr/lib/libSystem.dylib.  On 10.6, unfortunately, that (and 
other libs) is a 3-way universal files (i386, x86_64, and ppc) even in the 10.6 
SDK supplied with Xcode 4.2 for 10.6 despite the fact that the compilers 
provided with 4.x do not support building ppc binaries.  The problem shows up 
right away as the make dies quickly and it is easily fixed by specifying 
--with-universal-archs=intel.  Still, it would be nice to fix that.

--
keywords: +patch
stage: needs patch - patch review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file28917/issue11485_backport_27.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ned Deily]

Changes by Ned Deily n...@acm.org:


Added file: http://bugs.python.org/file28918/issue11485_backport_32.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ronald Oussoren]

Ronald Oussoren ronaldousso...@mac.com added the comment:

The 10.4 SDK needs to be changed in 2.7, 3.1 and 3.2 as well: the most recent 
version of Xcode no longer ships with the 10.4 SDK (and possibly  without the 
10.5 SDK as well, I'll writing this at the airport and haven't downloaded the 
latest release yet).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

Setting it to the version of the current OS is probably the least surprising. 
Agreed.

--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Santoso Wijaya]

Santoso Wijaya santoso.wij...@gmail.com added the comment:

 Running configure on a MacOSX system will set
 MACOSX_DEPLOYMENT_TARGET to 10.4, which is probably not optimal
 for anyone on a recentish system.

What's more, when I first tried to compile Python on Mac OS X, and I have 
MacPorts' version of Python as the default interpreter in the terminal, I get 
the following errors when trying to do bare `./configure; make`:

bash-3.2$ make 
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py,
 line 553, in module
main()
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py,
 line 535, in main
known_paths = addusersitepackages(known_paths)
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py,
 line 268, in addusersitepackages
user_site = getusersitepackages()
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py,
 line 243, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py,
 line 233, in getuserbase
USER_BASE = get_config_var('userbase')
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py,
 line 535, in get_config_var
return get_config_vars().get(name)
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py,
 line 434, in get_config_vars
_init_posix(_CONFIG_VARS)
  File 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/sysconfig.py,
 line 313, in _init_posix
raise IOError(msg)
IOError: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.4 but 10.6 during 
configure
make: *** [Include/Python-ast.h] Error 1


I worked around this by adding MACOSX_DEPLOYMENT_TARGET=10.6 to the configure 
script, but I have to remember to do that every time I configured a fresh clone 
of the source.

--
nosy: +santa4nt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ronald Oussoren]

Ronald Oussoren ronaldousso...@mac.com added the comment:

See Issue11487 for more discussion on the SDK issue.

As a workaround do touch  Include/Python-ast.* to ensure that the build won't 
try to rebuild the header files (those files are up-to-date, but the timestamps 
in a fresh checkout are the same as those of the source file and that causes a 
rebuild)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ronald Oussoren]

New submission from Ronald Oussoren ronaldousso...@mac.com:

(based on the fruitfull meating I had with Ned after the language summit at 
Pycon '11)

Running configure on a MacOSX system will set MACOSX_DEPLOYMENT_TARGET to 10.4, 
which is probably not optimal for anyone on a recentish system.  It would be 
better to set the deployment target to something more recent. There seem to be 
two options:

* set the deployment target to the current OS release by default
  (that is, 10.6 on a Snow Leopard system, 10.4 on a Tiger system)

* set the deployment target to 10.4 on OSX 10.4 and 10.5 on 
  later versions.

Setting it to the version of the current OS is probably the least surprising. 


Related to this: configure --enable-universalsdk selects the 10.4u SDK
by default. That would have to be changed at the same time, setting
the deployment target to 10.6 while still trying to use files from
the 10.4u SDK is not very useful.

I'd set the default value of the SDK to '/' on anything newer than OSX 10.4 and 
keep the 10.4u SDK on OSX 10.4 (because you cannot build universal binaries 
using the default system headers on a lot of 10.4 systems).

I'll work on a patch for the default branch during the sprints, and interesting 
question is if this should be backported.

--
assignee: ronaldoussoren
components: Build, Macintosh
messages: 130764
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Default SDK value on MacOSX needs changing
type: behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11485] Default SDK value on MacOSX needs changing

[Ronald Oussoren]

Changes by Ronald Oussoren ronaldousso...@mac.com:


--
versions: +Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11485
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com