Ned Deily <n...@acm.org> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11445>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
