Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Missing bufferoverflowU.lib

by phaylon (Curate)
on Mar 13, 2009 at 13:50 UTC ( #750416=note: print w/ replies, xml ) Need Help??


in reply to Missing bufferoverflowU.lib

I have no idea about development on Win32 whatsoever, but this non-Perl discussion seems to indicate the file was discontinued after version 6.0a of the Platform SDK.

HTH, phaylon


Ordinary morality is for ordinary people. -- Aleister Crowley


Comment on Re: Missing bufferoverflowU.lib
Re^2: Missing bufferoverflowU.lib
by BrowserUk (Pope) on Mar 13, 2009 at 16:44 UTC

    Yep. That's the root of the problem.

    AS built their win64 build with "Microsoft ® Windows Server® 2003 R2 Platform SDK", but that has been superseded by "Windows SDK for Windows Server 2008 and .NET Framework 3.5", and all pages for the former now link to the latter. And as you can never get a direct link that works for more than a day or so, it effectively makes it impossible to obtain the same compiler as AS used.

    I've succeeded(*) in hacking my way past that problem by creating a dummy bufferoverflowU.lib that exports a single static int call dummy. By placing that the appropriate place, the build completes.

    However, whilst the build succeed, I'm getting a runtime error R6034 when it tries to load the resultant dll. This is a problem that's come up here before (I think I may even have been the one that tracked down a solution to it?), but I cannot make it work for x64.


    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.
      I've succeeded(*) in hacking my way past that problem by creating a dummy bufferoverflowU.lib

      Wouldn't you be better off just removing bufferoverflowU.lib from the 'libs' and 'perllibs' listing in Config_heavy.pl ? Or is there still some real need for that library ?

      Cheers,
      Rob
        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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (12)
As of 2014-12-26 13:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls