Nick Glencross wrote: > My understand is that on Windows DLLs must be self-contained and cannot > have unreferenced symbols, and so I've linked against libparrot.so which > of course pulls in much of its code. I see this also being done in the > MSWin32 case...
Yes, Windows needs to know where the missing symbols come from. Isn't that the case on every platform? > However... now for the bit I don't understand. Globals are now going to > exist in both the executable and another copy in the dynamically loaded > library. How does this usually get resolved? Well, you've got a libparrot.dll. parrot.exe got to be linked against it, and so have the dynclasses. Once parrot.exe runs, it pulls in libparrot.dll. If a dynclass gets loaded, it also looks for its missing symbols from libparrot.dll, and finds them in the already loaded one. > At the moment I get a segfault in get_new_pmc_header in pmc.c when it > tried to access the wrong copy of the global Parrot_base_vtable which > hasn't been initialised (the code path is that loadlibs loads foo.dll > which in its load callback it calls pmc_new which eventually gets to > this routine). Yes, that's right. The dynclasses rely on an initialized libparrot.dll. But parrot.exe has its own static version, which is initialized and used by everything contained in parrot.exe - that is, everything except the dynclasses. Once a dynclass is loaded, it loads the libparrot.dll, which is utterly useless, as it is only used there. I've discussed this issue previously on this list, implemented a solution for the Microsoft toolchain (with all dynclasses tests passing), but the solution got rejected, so I decided to leave it to someone else. Ron
