I see the problem now. Using a --enable-shared configure similar to Skip's, the gcc step that builds python.exe is:

  gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \
      Modules/python.o \
      -L. -lpython2.7 -ldl  -framework CoreFoundation

What I failed to notice originally is that the MacPorts python27 port, which both Skip and I have installed, adds a link in /opt/local/lib to its framework lib:

/opt/local/lib/libpython2.7.dylib@ -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python

So since /opt/local/lib comes first on the lib list, that libpython2.7 is going to be found before the build directory's dylib.  Moving -L /opt/local/lib to after -L. does seem to fix the problem.

In the non-shared case, the gcc link step is:

  gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \
      Modules/python.o libpython2.7.a \
      -ldl  -framework CoreFoundation

so the local static lib is explicitly loaded and there shouldn't be a problem.

The shared-lib case is nasty in that you can easily link to the wrong lib without realizing it.  The Makefile (for 2.7 - py3k is similar) is:

# Build the interpreter
$(BUILDPYTHON):	Modules/python.o $(LIBRARY) $(LDLIBRARY)
		$(LINKCC) $(LDFLAGS) $(LINKFORSHARED) -o $@ \
			Modules/python.o \
			$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

I wonder whether $(LDFLAGS) can be safely moved to after $(BLDLIBRARY) without breaking some platform. And I suspect the problem is not unique to OS X but perhaps more likely there.