The motto of my last few days: "error LNK2019: unresolved external symbol"

Work on linking/error LNK2019: unresolved external symbol

The last two weeks I spent on fixing unresolved external symbols. While it was straight forward with GCC and clang to ignore unresolved symbols (i.e. implicit definitions in GCC or by passing "-undefined dynamic_lookup" to clang) at compile time, there seems to be no such option with MSVC.
Anyway, it's not a bad idea to fix these symbols as they can become runtime errors at some point, so tried to get this done.

Here is an excerpt from the list of failing symbols:

dl_nt.obj : error LNK2019: unresolved external symbol __imp_LoadStringA referenced in function DllMain
unicodeobject.obj : error LNK2019: unresolved external symbol __imp_CharPrevA referenced in function is_dbcs_lead_byte
stringobject.obj : error LNK2019: unresolved external symbol stringlib_partition referenced in function string_partition
stringobject.obj : error LNK2019: unresolved external symbol stringlib_rpartition referenced in function string_rpartition
stringobject.obj : error LNK2019: unresolved external symbol stringlib_count referenced in function string_count
typeobject.obj : error LNK2019: unresolved external symbol valid_identifier referenced in function type_new
JyNI.obj : error LNK2019: unresolved external symbol PyExc_WindowsError referenced in function initBuiltinExceptions
JyNI.obj : error LNK2019: unresolved external symbol backtrace_symbols referenced in function jPrintCStackTrace
errors.obj : error LNK2019: unresolved external symbol Py_UniversalNewlineFgets referenced in function PyErr_ProgramText
pythonrun.obj : error LNK2019: unresolved external symbol alloca referenced in function Py_FatalError


Unfortunately I was not yet able to fix all of these, but I expect to have this done within some more days of work.
(It is just time consuming to figure out each of these and attach the necessary bits to JyNI or the linking process.)
Already got plenty of them solved, keep fingers crossed that the rest will be done soon...

support multiprocessing

As kind of a sidequest I investigated what it takes to support the multiprocessing extension. Originally I stumbled over demand for it in context of ImageJ.
So far, it turned out that Jython's subprocess implementation lacks _args_from_interpreter_flags. I assume this comes because std-lib hasn't been
synchronized with CPython for a very long time. Anyway, it was a trivial fix to simply add this part from current CPython 2.7.13 subprocess implementation.
With that fixed, it comes to a segmentation fault while importing _multiprocessing (in exploreJyGCHeadLinks, so it's another issue with GC). I will continue investigation on this front...

Comments

Popular posts from this blog

Final report: ctypes and NumPy work with JyNI on Windows

Lessons learned with Visual Studio, C89 and the preprocessor