Running this on Mac OS X:
$ ./configure --with-pydebug --enable-framework
$ make

I get this:
(...)
ar cr libpython3.0.a Modules/config.o Modules/getpath.o Modules/main.o 
Modules/gcmodule.o 
ar cr libpython3.0.a Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  
Modules/_codecsmodule.o  Modules/_fileio.o  Modules/zipimport.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.0.a
/usr/bin/install -c -d -m 755 Python.framework/Versions/3.0
if test ""; then \
        gcc -o Python.framework/Versions/3.0/Python -arch i386 -arch ppc -dynamiclib 
\
                -isysroot "" \
                -all_load libpython3.0.a -Wl,-single_module \
                -install_name 
/Library/Frameworks/Python.framework/Versions/3.0/Python \
                -compatibility_version 3.0 \
                -current_version 3.0; \
        else \
        /usr/bin/libtool -o Python.framework/Versions/3.0/Python -dynamic  
libpython3.0.a \
                 -lSystem -lSystemStubs -arch_only i386 -install_name 
/Library/Frameworks/Python.framework/Versions/3.0/Python -compatibility_version 3.0 -
current_version 3.0 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/3.0/Python] Error 1

If using only --with-pydebug it works fine.

I can reproduce this problem on both an intel and a powerpc mac.

With '--with-pydebug --enable-framework --enable-universalsdk', the 
behavior is very much different:

On a powerpc mac, configure fails with
  'checking size of wchar_t...configure: error: cannot compute sizeof 
(wchar_t)'

On an intel mac, configure and make succeed; a test fails, though (which 
normally passes, e.g. when no arguments at all were passed to 
configure). The failing test is: test_xmlrpc.

Which versions of OS X, please?  And which Xcode versions?

powerpc : macosx 10.4.10, xcode 2.4.1 (gcc 4.0.1 build 5367)
intel : macosx 10.4.10, xcode 2.5pre (gcc 4.0.1 build 5370)

I'm using these versions:
intel: macosx 10.4.10, xcode 2.4.1 (gcc 4.0.1 build 5367)

Tried again with current revision (58153) and with --enable-universalsdk 
it built just fine. Without it, I still get the same error.

Can you please try XCode 2.5? See issue 3533 for a report that says that
upgrading solved the problem.

Configuring with '--with-pydebug --enable-framework --enable-universalsdk' 
(and invoking make afterwards) certainly works now for me.

I'm running XCode 3.1 -- or more importantly 'i686-apple-darwin9-gcc-4.0.1 
(GCC) 4.0.1 (Apple Inc. build 5484)' -- on OS X 10.5.4.

Still fails for me on OS X 10.4.11 with latest available xcode (2.5).
This is on PPC with the current stable release of python (2.5.2).

---configure script---
../configure \
        --enable-framework \
        LDFLAGS=-L/usr/local/lib \
        CFLAGS=-I/usr/local/include \
        CPPFLAGS=-I/usr/local/include \
        --with-pydebug \

---error from make---
if test ""; then \
        gcc -o Python.framework/Versions/2.5/Python -arch i386 -arch ppc
-dynamiclib \
                -isysroot "" \
                -all_load libpython2.5.a -Wl,-single_module \
                -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python \
                -compatibility_version 2.5 \
                -current_version 2.5; \
        else \
        /usr/bin/libtool -o Python.framework/Versions/2.5/Python
-dynamic  libpython2.5.a \
                 -lSystem -lSystemStubs -arch_only ppc -install_name
/Library/Frameworks/Python.framework/Versions/2.5/Python
-compatibility_version 2.5 -current_version 2.5 ;\
fi
ld: Undefined symbols:
___eprintf
/usr/bin/libtool: internal link edit command failed
make: *** [Python.framework/Versions/2.5/Python] Error 1

Is this still relevant?

Yes, it is still an issue for all active branches.  I'm working on a patch for it.

The attached patch removes the call to libtool and always links the framework using gcc (as was already done for universal builds).

With this patch I can build the framework using the following configure command-line on OSX 10.6:

   ../configure --with-pydebug --enable-framework CC=gcc-4.0

Without this patch that build will fail due to a link error (the exact error is different than the one in the initial message in this issue, but should basically be the same problem).

I haven't fully tested the patch yet, in particular I haven't run the unittests yet and haven't tested on a 10.4 system (because I'm on a different continent than my OSX 10.4 box at the moment)

The patch, as is, fixes another build failure mode that has been reported (http://article.gmane.org/gmane.comp.python.general/685151):

  ./configure --enable-framework ; make

I verified that 3.2 builds without the patch fail on both 10.5 ppc and 10.4 ppc (10.4 fails thusly):

  ld: Undefined symbols:
  ___divdi3
  ___moddi3
  ___fixdfdi
  /usr/bin/libtool: internal link edit command failed

and builds works and tests pass with the patch on both.

It doesn't totally fix yet another use case (http://permalink.gmane.org/gmane.comp.python.general/685512), that of building an i386-only Python on a 10.6 64-bit-capable system:

  ./configure '--enable-framework' 'CFLAGS=-arch i386' 'CPPFLAGS=-arch i386' 'LDFLAGS=-arch i386'

With the patch, the build gets a bit further and the modified libpython make step emits the warning:
  ld: warning: in libpython3.3m.a, file was built for unsupported file format which is not the architecture being linked (x86_64)

but then the python.exe build step fails with:
  ld: warning: in Python.framework/Versions/3.3/Python, file was built for unsupported file format which is not the architecture being linked (i386)

The problem is that the libpython step (both originally and in the patch) does not take LDFLAGS into account.  Changing one line in the patch fixes that:

        $(CC) -o $(LDLIBRARY) @UNIVERSAL_ARCH_FLAGS@ -dynamiclib \
-               @FRAMEWORK_LINK_FLAGS@ \
+               @FRAMEWORK_LINK_FLAGS@ $(PY_LDFLAGS) \
                -all_load $(LIBRARY) -Wl,-single_module \

Good catch, and that would also allow dropping the change to configure.in (which would only ensure that -isysroot gets defined correctly).

I've added a new patch which only updates makefile.pre.in.

The patch has a spurious backslash at the end of the $(CC) command, but should otherwise be OK.

I'm currently running the testsuite in will later today push the fix to the repository.

New changeset 7af5a9298251 by Ronald Oussoren in branch '3.1':
Fixes #1099: Mac compile fails with pydebug and framework enabled
http://hg.python.org/cpython/rev/7af5a9298251

New changeset e8679f07badd by Ronald Oussoren in branch '3.2':
Issue #1099: Fix the build on MacOSX when building a framework with pydebug using GCC 4.0.
http://hg.python.org/cpython/rev/e8679f07badd

New changeset 4c651c1abd28 by Ronald Oussoren in branch 'default':
Issue #1099: Fix the build on MacOSX when building a framework with pydebug
http://hg.python.org/cpython/rev/4c651c1abd28

New changeset bcca0a6ebbd2 by Ronald Oussoren in branch '2.7':
Issue #1099: Fix the build on MacOSX when building a framework with pydebug using GCC 4.0.
http://hg.python.org/cpython/rev/bcca0a6ebbd2