Or is there still some real need for that library ?

There doesn't appear to be, as my hacked bufferoverflowU.lib was sufficient to allow the build to complete. As does the real thing now I've got my hands on a copy. So just removing it from the config would probably be the best solution, now that I know.

However, whichever way I do it, I'm still getting the same runtime error when I try to load the resultant dll:

R6034: An application (...\perl.exe) made an attempt to load the C-run
+time library incorrectly.
[download]

This is the 'manifest' issue. Looking in the blib, the manifest has been produced and it's contents appear to match the imports contained in the dll.

But if I try to extract the manifect from the dll, it isn't there which suggests to me that the generated makefile has never attempted (or attempted but failed) to attach the manifest. There is nothing in the console output from the make to suggest that it was ever attempted.

Looking at the makefile, there is a manifest target:

manifest :
    $(PERLRUN) "-MExtUtils::Manifest=mkmanifest" -e mkmanifest
[download]

But if I attempt to invoke that target:

C:\Perl64\packages\Devel-Size-0.72>nmake manifest

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

'manifest' is up-to-date
[download]

Which is unsurprising really as the only place that target ever appears as a dependancy is under the 'phony' target. And the 'manifest' target itself has no dependancies and so will never be invoked. Quite how/when that target is ever meant to be invoked is beyond me?

If I hack the makefile and change the manifest target to:

manifest : $(INST_DYNAMIC) $(INST_DYNAMIC).manifest
    mt -manifest $(INST_DYNAMIC).manifest -outputresource:$(INST_DYNAM
+IC);2
[download]

I can the invoke it manually and it completes correctly. After that, make test and make install run perfectly and the module is useable and works.

So, my conclusion is that the makefile is borked and probably always has been since the manifest handling was added, but because almost no one uses the MS compiler suites, it simply never showed up.

To fix the problem properly, two things are left to be done.

1. The manifest target needs to be made a dependancy of something to cause it to be invoked. I thought the 'linkext' target made sense:

   # --- MakeMaker linkext section:
   
   linkext :: $(LINKTYPE) manifest
       $(NOECHO) $(NOOP)
   [download]

   And it does work, causing the manifest to be attached after the link step. But when you do a make install, the manifest target gets re-invoked. It doesn't harm, but it would be better if that didn't happen.

2. Makefile.pl needs to be modified to reflect the above changes.

   At that point (as always), I draw a blank trying to reverse step my way through the steaming pile of EU::MM stuff to produce a patch. It is beyond my capabilities. Any thoughts?

For now, as I have other windmills I'm currently tilting at, I'm going to code up a perl script (fixmakefile.pl) to patch the makefile after the makefile.pl generation step.

Update: Here my fixmakefile.pl for any other intrepid Win64/2008SDK users until the powers that be work out how to do this properly. Stick it somewhere in your path (eg. perl64/bin) and invoke it without parameters between the first two steps of the build sequence:

perl Makefile.pl
perl fixmakefile.pl   <<<<additional step>>>>
nmake
nmake test
nmake install
[download]

fixmakefile.pl

#! perl -sw
use strict;

open  IN, '<', 'Makefile'       or die "Makefile': $!";
open OUT, '>', 'Makefile.fixed' or die "Makefile.fixed $!";

select OUT;

while( <IN> ) {
    if( m[^linkext] ) {
        s[$][ manifest] and print or die 'Failed to append to linkext'
+;
    }
    elsif( m[^manifest] ) {
        s[$][ \$(INST_DYNAMIC) \$(INST_DYNAMIC).manifest]
            and print or die 'Failed to append to manifest';
        print "\tmt -manifest \$(INST_DYNAMIC).manifest -outputresourc
+e:\$(INST_DYNAMIC);2\n";
        print '# ' . <IN>; ## disable EU::MM mkmanifest crap
        last;
    }
    else {
        print;
    }
}

print while <IN>;

close IN or die "Closing original makefile failed: $!";
rename 'Makefile', 'Makefile.gen'
    or die "Rename original makefile failed: $!";

close OUT or die "Closing fixed makefile failed: $!";
rename 'Makefile.fixed', 'Makefile'
    or die "Rename fixed makefile failed: $!";
[download]

Looking in the blib, the manifest has been produced

No such file in my blibs. Does that merely indicate that the manifest has been attached to the dll ?

I'm getting the same Makefile as you (which is to be expected, as we're using the same build of perl), but no manifest problems. I'm using Windows Server 2003 R2 SDK, whereas you're using a 2008 SDK - which, no doubt, accounts for the difference (somehow).

Cheers,
Rob

Looking in the blib, the manifest has been produced

No such file in my blibs. Does that merely indicate that the manifest has been attached to the dll ?

I'm getting the same Makefile as you (which is to be expected, as we're using the same build of perl), but no manifest problems. I'm using Windows Server 2003 R2 SDK, whereas you're using a 2008 SDK - which, no doubt, accounts for the difference (somehow).

As with you, I see no mention of "manifest" during the build process.

Cheers,
Rob