Alexander> I cannot reproduce this on my Mac. It looks like you may
Alexander> have an out of date python.exe in your sandbox. Please check
Alexander> that
Alexander> $ nm python.exe | grep PyObject_NextNotImplemented
Alexander> 00052940 T __PyObject_NextNotImplemented
Alexander> has a "T" in the second column.
Alexander> Note that this symbol seem to have been added recently:
...
I see what the problem is now. I configured with --enable-shared. Even
though my sandbox was up-to-date, my python.exe was current and my
libpython2.7.dylib held the symbol in question the *installed* version of
libpython2.7.dylib didn't have the symbol:
% nm python.exe | grep PyObject_NextNotImplemented
% nm libpython2.7.dylib | egrep PyObject_NextNotImplemented
00054200 T __PyObject_NextNotImplemented
% nm /Users/skip/local/lib/libpython2.7.dylib | egrep
PyObject_NextNotImplemented
%
I've been bitten by this before. When building with --enable-shared the
executable appears to have the installed shared library location bound into
it:
% otool -L python.exepython.exe:
/Users/skip/local/lib/libpython2.7.dylib (compatibility version
2.7.0, current version 2.7.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.3)
Is this something that we can fix/work around? It seems to me like a wart,
probably platform-dependent.
Alexander> I am puzzled, however, that you don't see problems in a
Alexander> non-coverage run.
Yeah, that mystifies me as well, especially given the above output from nm
and otool.
Skip
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
