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 ${cur_target} '>' 10.2; then
                    cur_target=10.3
            fi
            if test "${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 ${cur_target} '>' 10.2 -a ${cur_target} '<' 10.5 ; then
                    cur_target=10.3
            fi

(which works).

Skip

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.

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

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.

Skip could you please answer the questions in msg83149?

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.