Front page | perl.perl5.porters |
Postings from April 2007
Yitzchak Scott-Thoennes wrote: > Steve Hay <steve.hay <at> uk.radan.com> writes: >> Recent smokes of mine have shown that the Win32CORE changes are causing >> problems with non-threaded builds when using MinGW. > > I'm guessing there's something (a define?) missing from Win32CORE.c > that would be there if it were a .c file produced from an .xs file. > > I'd wanted to make it a regular .xs file just to prevent problems > like this from arising, but didn't manage to find the tuits. > > I may or may not get around to doing this; if someone else does, > that'd be terrific. Unfortunately, I don't think that is the problem. Win32CORE.c can easily be turned into a .xs file by just renaming it! It's contents are very similar to the contents of Win32.xs, so it doesn't need any changes, and doing the rename makes no difference to this problem. The real problem, however, seems to be that static extensions in general don't work correctly with a non-threaded build of perl. For example, try these build options: USE_MULTI=undef USE_ITHREADS=undef USE_IMP_SYS=undef STATIC_EXT=Compress/Raw/Zlib and you'll find that the GCC linker spits out a huge array of errors relating to Zlib.a when it comes to linking perl59.dll, e.g. ..\lib\auto\Compress\Raw\Zlib\Zlib.a(Zlib.o)(.text+0x22):Zlib.c: undefined reference to `_imp__win32_errno' ..\lib\auto\Compress\Raw\Zlib\Zlib.a(Zlib.o)(.text+0x2d):Zlib.c: undefined reference to `_imp__win32_strerror' ..\lib\auto\Compress\Raw\Zlib\Zlib.a(Zlib.o)(.text+0x5e2):Zlib.c: undefined reference to `_imp__PL_curcop' ..\lib\auto\Compress\Raw\Zlib\Zlib.a(Zlib.o)(.text+0x5ea):Zlib.c: undefined reference to `_imp__PL_compiling' [...] If you try with VC6 instead of GCC then you get a bunch of warnings instead: LINK : warning LNK4049: locally defined symbol "_PL_sv_undef" imported LINK : warning LNK4049: locally defined symbol "_PL_stack_max" imported LINK : warning LNK4049: locally defined symbol "_PL_curpad" imported LINK : warning LNK4049: locally defined symbol "_PL_op" imported LINK : warning LNK4049: locally defined symbol "_PL_stack_base" imported LINK : warning LNK4049: locally defined symbol "_PL_markstack_ptr" imported LINK : warning LNK4049: locally defined symbol "_PL_stack_sp" imported LINK : warning LNK4049: locally defined symbol "_PL_curcop" imported LINK : warning LNK4049: locally defined symbol "_win32_strerror" imported LINK : warning LNK4049: locally defined symbol "_win32_errno" imported LINK : warning LNK4049: locally defined symbol "_PL_compiling" imported LINK : warning LNK4049: locally defined symbol "_PL_Xpv" imported LINK : warning LNK4049: locally defined symbol "_PL_Sv" imported LINK : warning LNK4049: locally defined symbol "_PL_sv_no" imported LINK : warning LNK4049: locally defined symbol "_PL_sv_yes" imported LINK : warning LNK4049: locally defined symbol "_PL_scopestack_ix" imported LINK : warning LNK4049: locally defined symbol "_PL_unitcheckav" imported where the symbols listed above are exactly those that GCC gives errors on. This clearly hasn't been noticed in the past because people don't often link extensions statically, but now that all Win32 perl builds have the Win32CORE extension statically linked in by default it becomes a more significant problem: GCC can't build a non-threaded perl on Win32 any more (and as above VC6 outputs warnings like the above relating to the same set of symbols as GCC errors on). Clearly something is amiss with the static extension build procedure, and it needs fixing now that we build a static extension by default. I'm just not sure exactly what is wrong or how to fix it yet :-( --Thread Previous