Author ned.deily
Recipients eric.araujo, ned.deily, ronaldoussoren, skip.montanaro
Date 2011-03-10.06:58:06
SpamBayes Score 2.10498e-13
Marked as misclassified No
Message-id <>
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)
			Modules/python.o \

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.
Date User Action Args
2011-03-10 06:58:07ned.deilysetrecipients: + ned.deily, skip.montanaro, ronaldoussoren, eric.araujo
2011-03-10 06:58:07ned.deilysetmessageid: <>
2011-03-10 06:58:06ned.deilylinkissue11445 messages
2011-03-10 06:58:06ned.deilycreate