Issue 4834: Trouble configuring with icc on Mac OS X 10.5 (original) (raw)

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/49084

classification

process

Created on 2009-01-04 18:08 by skip.montanaro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg79074 - (view)	Author: Skip Montanaro (skip.montanaro) *	Date: 2009-01-04 18:07
I get this error when trying to configure with Intel's icc on my Mac (Intel, 10.5.6, Xcode 3.1.2): >> configure:10332: checking size of size_t >> configure:10637: icc -o conftest -g -O2 conftest.c >&5 >> ld: library not found for -lgcc_s After a couple notes to python-dev and a little bit of sleuthing with -v I discovered that it was generating -lgcc_s instead of -lgcc_s.10.5 in the ld line. I narrowed the problem down to this code in configure.in: # Calculate the right deployment target for this build. # cur_target=`sw_vers -productVersion | sed 's/\(10\.[[0-9]]*\).*/\1/'` if test curtarget′>′10.2;thencurtarget=10.3fiiftest"{cur_target} '>' 10.2; then cur_target=10.3 fi if test "curtarget′>′10.2;thencurtarget=10.3fiiftest"{UNIVERSAL_ARCHS}" = "all"; then # Ensure that the default platform for a 4-way # universal build is OSX 10.5, that's the first # OS release where 4-way builds make sense. cur_target='10.5' fi CONFIGURE_MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET-${cur_target}} # Make sure that MACOSX_DEPLOYMENT_TARGET is set in the # environment with a value that is the same as what we'll use # in the Makefile to ensure that we'll get the same compiler # environment during configure and build time. MACOSX_DEPLOYMENT_TARGET="$CONFIGURE_MACOSX_DEPLOYMENT_TARGET" export MACOSX_DEPLOYMENT_TARGET EXPORT_MACOSX_DEPLOYMENT_TARGET='' The test of cur_target against 10.2 seems suspicious. This code dates from r65061 (checked in by Benjamin last July) which states: #3381 fix framework builds on 10.4 Maybe it should be if test curtarget′>′10.2−a{cur_target} '>' 10.2 -a curtarget′>′10.2−a{cur_target} '<' 10.5 ; then cur_target=10.3 fi (which works). Skip
msg79089 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2009-01-04 22:38
I don't think this is a bug. The change actually dates from r45800; I believe the intention is that the Python binaries work on 10.3 and newer, unless you use 10.2 or older to build them (in which case the deployment target is set to the build machine version). So I propose to reject this report as invalid.
msg79097 - (view)	Author: Skip Montanaro (skip.montanaro) *	Date: 2009-01-04 23:34
Martin> I don't think this is a bug. The change actually dates from Martin> r45800; I believe the intention is that the Python binaries work Martin> on 10.3 and newer, unless you use 10.2 or older to build them Martin> (in which case the deployment target is set to the build machine Martin> version). Martin> So I propose to reject this report as invalid. I don't see how Python can require an optional piece of Xcode. I only build Python for my own use. I shouldn't be forced to build exeutables which will run on a version of the operating system I no longer have. I think the code in configure.in has to be smarter and detect that the presence or absence of the 10.3 compatibility bits in Xcode. Skip
msg83149 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-03-04 22:18
Skip: could you please explain which bit of Xcode you didn't install? The compile should work regardless of installing 10.3 SDK support. The code you mention in your report sets MACOSX_DEPLOYMENT_TARGET to 10.3 on 10.3 systems or later, unless you explictly set it to another version yourself. This matches the default compiler settings on at least 10.4 systems. I just noticed that the default on 10.5 systems to compile for the current OS release. The intention of the code is to allow the resulting binaries to run on as many platforms as possible. Note that you can easily work around this issue by explicitly setting MACOSX_DEPLOYMENT_TARGET to 10.5.
msg88095 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-05-19 19:52
Skip could you please answer the questions in ?
msg97968 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2010-01-17 19:29
I've committed a small change in r77587 (trunk) that disables usage of the 10.4u SDK when that SDK is not present. That may or may not fix this issue. I'm not going to do anything more to this issue and am therefore closing it.