The parrot needs help, hopefully before tomorrow's release. There are two issues with linking against libparrot.dll on win32:
1. It refuses to export the "_PMCNULL" symbol (the PMCNULL global variable defined at the top of src/pmc.c), and thus, embedders cannot use the PMC_IS_NULL macro. This causes t/src/compiler.t to fail. Jerry added a workaround in r20641, declaring a local variable PMCNULL within the test code, to get it to pass. Unfortunately, this workaround causes Darwin to fail with the message "ld: multiple definitions of symbol _PMCNULL". 2. The filenames written by Configure.pl are wrong. This causes the linker command line to get the wrong library-name. It looks like this: # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t\src\string_3.obj src\parrot_config.obj -out:t\src\string_3.exe -Lblib\lib libparrot$(A) kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 80 # LINK : fatal error LNK1104: cannot open file 'libparrot$(A).obj' The variable $(A) is not expanded properly in the win32 shell. Quoth the Jerry: [18:30] <@particle> with gcc, you do "-lparrot" to find the library [18:31] <@particle> on win32, you do "libparrot.lib" [18:31] <@particle> in Parrot::Config, it's stored as "libparrot$(A)" [18:31] <@particle> during make, that evaluates to "libparrot.lib" [18:31] <@particle> but not in the shell, which is where that value is being used [18:31] <@particle> 2 ways to fix [18:32] <@particle> 1: put something in Parrot::Config that has what win32 needs [18:32] <@particle> 2: make a function available in Parrot::Config that resolves the variables, and call the func Once these two issues are resolved, the extra PMCNULL variables should be removed from t/src/compiler.t, which will make Darwin happy too. :) Please help! I'm clueless about win32... Mark
