I configured the build:
    ./configure --with-system-ffi --enable-shared --with-computed-gotos --prefix=$HOME/.local/python3 

Ran make with 4 jobs (make -j4), and got:
    make: *** No rule to make target `libpython3.2m.dylib', needed by `python.exe'.  Stop.
    make: *** Waiting for unfinished jobs....

It seems there might be a $(VERSION)/$(LDVERSION) problem somewhere in the Makefile, but I'm uncertain where the issue is exactly.  Looks like using --enable-framework instead of --enable-shared works, but I'd rather not have the framework right now.

I have not tried 3.2 yet, but Issue 11046 may be of interest for you!
Try the undocumented:

configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5

in the meanwhile - it may help you out.

Can you please attach your Makefile file?

In Makefile.pre.in, I see:

libpython$(VERSION).dylib: $(LIBRARY_OBJS)

VERSION should be 3.2, only LDVERSION is the VERSION + the ABI flags (eg. 3.2dm). And I don't see any usage of libpython$(LDVERSION).dylib in Makefile(.pre.in).

(You might also try "make SHELL='bash -x'" or "make -d" to get more information)

Ah, there is also Mac/Makefile.in: attach also Mac/Makefile.

(and there is also Mac/PythonLauncher/Makefile.in, but I don't think that the issue comes from this file)

((can it be related to python*-config program?))

@Georg: Is this issue a release blocker?

Ooops.  In fact 3.2 did well with that undocumented thing either.

Here is the top-level Makefile.

Interesting.  I don't see a Mac/Makefile.  Perhaps it's only pulled in with the framework build?

MACOSX_DEPLOYMENT_TARGET=10.5 made no bit of difference for me.  Steffen, I take it that it didn't help you either?  You said "did well", but the rest of your text indicates otherwise. :-)

Ah ok, the issue comes from configure.in near line 779:

    Darwin*)
    	LDLIBRARY='libpython$(LDVERSION).dylib'
	BLDLIBRARY='-L. -lpython$(LDVERSION)'
	RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'
	;;

The problem is that configure.in uses libpython$(LDVERSION).dylib, whereas Makefile.pre.in uses libpython$(VERSION).dylib. Attached patch changes Makefile.pre.in to use libpython$(LDVERSION).dylib.

I don't know if this change is correct or not. I don't know if the options for the compilation in framework mode should be changed too. I don't know what is the Mac framework :-)

See also http://www.python.org/dev/peps/pep-3149/ (ABI version tagged .so files)

Aeh, your patch does it.
You may be interested of all Mac OS X compilation notes??

/usr/bin/ranlib: file: libpython3.2m.a(dynamic_annotations.o) has no symbols
/usr/bin/ranlib: file: libpython3.2m.a(pymath.o) has no symbols
ranlib libpython3.2m.a
ranlib: file: libpython3.2m.a(dynamic_annotations.o) has no symbols
ranlib: file: libpython3.2m.a(pymath.o) has no symbols
/usr/bin/gcc   -framework CoreFoundation -o python.exe Modules/python.o libpython3.2m.a -ldl  -framework CoreFoundation     
building dbm using ndbm
ld: warning: directory '/usr/lib/termcap' following -L not found
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from /Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:MULTIPLE: warning: function declaration isn’t a prototype
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from /Users/steffen/arena/code.extern.repos/py3k.hg/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:MULTIPLE: warning: function declaration isn’t a prototype
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
/Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:49: warning: function declaration isn’t a prototype
/Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:379: warning: function declaration isn’t a prototype

The patch definitely helps.  However, once I get it installed, there seems to be no time module:
   >>> import time
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   ImportError: No module named time

So I think there's probably still something not quite right.

"import time" works for me with the patched build.  There should have been a warning message during the build if the time module failed to build.  Perhaps you have a file permissions problem?  Check your lib/python3.2/lib-dynload/ for file time.so 

BTW, Victor's supplied patch is fine for fixing the shared lib target but should not include the framework build changes - that's an unrelated issue.  I will upload a revised patch for review after completing some more tests.  This should be included in 3.2final. And we have a hole in building and testing shared library configurations on OS X, even though that configuration isn't used as much as the OS X framework one.

Looks like the time module is being built:
    ./build/lib.macosx-10.4-x86_64-3.2/time.so

But none of the shared modules are being installed, as lib/python3.2/lib-dynload is completely empty.

You did run "sudo make install"?

I'm installing into an area that I own ($HOME/.local/python3), so no need for sudo.  I just ran make install.

'make install' works for me as well (OSX 10.6, configure --prefix=/tmp/python32).

Could you attach the output of "make install", with some luck there will be a clear indication of why the install doesn't work on your machine.

Attached the output.

This one is my fault.  I have a .pydistutils.cfg that was causing them to be installed somewhere else or not at all. :-(  Moving my custom config out of the way, I'm good.  I'm not sure what's happening there, but that's a different problem. :-)

Here's a minimal patch (a subset of Victor's original) that fixes the release blocker issue.  It has been tested in both a shared library build (which now works) and a framework build (which is not affected as expected).  I recommend that it be applied before 3.2final.

Looks good to me. I guess it needs Georg's approval, though.

Committed as r88439 in py3k.

Does this need to be backported?

No backport is needed. The problem was introduced during the 3.2 development cycle by the ABI Version Tagged .so Files feature (PEP 3149).