I tried changing the s/// to:The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after "Makefile" and moving $(INST_DYNAMIC) to a different target in MY::top_targets. (Where INST_BOOT is run from, I dunno). But dynamic no longer matches /Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment "problems with things finding libareq.so, sort out later" leads me to believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to s{ \$\(INST_DYNAMIC\) }{}g; s{ \$\(INST_BOOT\) }{}g; should "fix" the symptoms by restoring the hack for a quick fix.
$string =~ s{ \$\(INST_DYNAMIC\)}{}g; $string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE) $(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE 'dynamic' to the Win32-specific section. That seems to get me back to square one - the Makefile contains:
For a longer term solution, try removing the MY::dynamic and MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT) $(NOECHO) $(NOOP)
and the build fails as it originally did with:
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
Only the fix previously posted by Stas (adding 'SKIP' => [qw(dynamic dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so far, but Joe had a problem that...
Steve