Michael G Schwern wrote:

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.

I tried changing the s/// to:

   $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'


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.


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:

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



Reply via email to