Karl Nelson <nelso...@llnl.gov> added the comment:
I attempted another deep dive on this one. 1) Removed manual library add platform_specific['libraries'] = ['Advapi32'] No change. 2) Compared symbol wise imports Two imports changed PyIndex_Check PyObject_CheckBuffer plus one additional "fflush" dependency in api-ms-win-crt-stdio-l1-1-0.dll 3) Compared symbol wise exports No changes detected. 4) Disassembled both binaries Other than a addressing that is about a 0x1000 change in the relocation tables. Guessing that this is just a change in the number of pages. There were functional changes likely related to Python macros differences. 5) Removed all references to printf and flush to remove api-ms-win-crt-stdio-l1-1-0.dll dependency. No change. 6) Scanned the changelog and Code changes for the past year in Python/dynload_win.c. Nothing appears likely to trigger this change. 7) Deleted the _jpype module entirely to verify that the error message is related to the copy that I am working on and not some other copy on system. Error message changes to "ModuleNotFoundError: No module named '_jpype'" 8) Scanned the source code for static variables. None detected thus far. But it is a many hours long process. Structurally these should not exist based on the module design. Statics found thus far. 2 jobject and jmethodID pointer types One C++ class called PLATFORM_ADAPTER which is the required routine determining whether to load jvm.dll or jvm.so using LoadLibrary or dlopen or shload. The global pointer to the context C++ class; a bunch of statics related to logging when enabled. Python C style structure definitions. Everything was a primitive or pointer with the exception of one class. All pointers I found were initialized to constant values. I rewrote the PLATFORM_ADAPTER to use a pointer rather than be initialized at load time. No joy. (after scanning through 17k lines of code take break and ponder life) It is certainly possible I missed something here but it looks pretty unlikely this is the source of the error. 9) Verified that the behavior does not occur on Python 3.8.5 with the current source code. Pass. This only happens on Python 3.9.0 10) Scanned the linker line for differences. One major difference. In Python 3.8 the linker line contains quotes around all the arguments while in Python 3.9 the linker line is missing the quotes on all /LIBPATH statements. However this must be a logging difference as the statement without the quotes would not work. 11) Manually ran linker command. Nothing changed, same behavior. So link command is a red herring. 12) Profit??? Okay I have once again exhausted everything that I can think of on the JPype side. So that leaves something in the build process that does not appear in the logs, a symbol conflict that so how only triggers on one path, or Python3.9.0 has a corrupt build in the wild. Steve is there anything else that I can try here? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42529> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
