Jonathan Worthington <[EMAIL PROTECTED]> wrote: > "Leopold Toetsch" <[EMAIL PROTECTED]> wrote: >> >> 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. >> > 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.
> 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? Yep, that's correct. I had that during my first experiments with loadable classes in linux too. Studying linker flags up and down led to the current link flag settings "-Wl,-E" for gcc. You have to convince the linker that unknown symbols in the shared library have to be resolved against libparrot dynamically, when the library is loaded, instead of duplicating globals and pulling in functions from that libparrot. This may work with some linker flags, via the .def file or by some __declspec() magic. You might have a look at perl5 source, albeit I don't know, if shared libs are supported for Win32. Reading docs and/or asking in a win programming newsgroup might help too. > Jonathan leo
