Jonathan Worthington <[EMAIL PROTECTED]> wrote:OK, you were right. Once I inserted __declspec(dllexport) into the declaration of Parrot_lib_python_group_load, Parrot_dlsym returned the address of the function in the DLL and it was called. I'll fix up a patch to get that inserted.OK, with the attached patch (which feels kinda hacky, but works) the build
completes. That's the good news.
Thanks, applied.
... The bad news is that almost all of the dynclasses tests fail.
I assume that the dynamic python lib has to export public symbols. You could run one of the failing tests with a debugger and check the Parrot_load_lib() steps.
With that working, there's still a problem. Parrot would (silently) exit and never get past the loadlib line in the IMC file. Tracing the problem, I found that it occurred in get_new_pmc_header, called from pmc_new_noinit from pmc_new from Parrot_lib_python_group_load, on the line:-
VTABLE *vtable = Parrot_base_vtables[base_type];
Because Parrot_base_vtables was null.
My python_group.dll is almost 2MB in size. I'm thinking that when it's being linked, it is linking a separate copy of Parrot (from libparrot_s.lib, which I added to the link line to make the build not complain about missing symbols). That means different globals, which leads to the problem. Might my analysis be correct, and any ideas on where to go from here?
Thanks,
Jonathan
