Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^4: Missing bufferoverflowU.lib

by BrowserUk (Patriarch)
on Mar 14, 2009 at 03:17 UTC ( [id://750555]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Missing bufferoverflowU.lib
in thread Missing bufferoverflowU.lib

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.

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

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

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

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)

    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

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: $!";

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^5: Missing bufferoverflowU.lib
by Anonymous Monk on Mar 14, 2009 at 03:51 UTC
    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
      I don't know about Perl's tool chain, but the ExtUtil::MakeMaker tool chain deletes the manifest after merging it in.
      $(LD) ... if exist $@.manifest mt -nologo -manifest $@.manifest -outputresource: +$@;2 if exist $@.manifest del $@.manifest});
Re^5: Missing bufferoverflowU.lib
by Anonymous Monk on Mar 14, 2009 at 03:52 UTC
    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
      I'm using Windows Server 2003 R2 SDK, whereas you're using a 2008 SDK - which, no doubt, accounts for the difference (somehow).

      Rob, I get the distinct impression that 2003 is long enough ago that the whole 'manifest' issue hadn't yet raised its ugly head, and that it has never been retro-fitted into the 2003SDK.

      Part of me wishes it was still possible to download the 2003SDK, but then the issue would have just been deferred until later anyway.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://750555]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (4)
As of 2024-03-29 00:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found