BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

This is effectively a follow-up to the issue I raised in Re^4: Missing bufferoverflowU.lib.

Later versions of MSVC compiler suites require an additional step in the build process to attach a 'manifest' resource to executable binaries (.exes & .dlls). The manifest files themselves are produced by the linker automatically. All that is required is to attach those files to the binaries (also produced by the linker) using mt.exe

(Quite why the linker can't do this for us automatically is moot question!).

Without this step being invoked, any attempt to load the dlls results in runtime error: 

R6034: An application has made an attempt to load the C runtime librar
+y incorrectly.

[download]

The problem is, that existing EU::MM (and similar) produced makefiles have a 'manifest' target and the command to invoke mt.exe to perform the attachment, but that target does not have any dependancies and so is never invoked.

Whilst I can hack my way past the problem for individual makefiles--by modifying the makefile before using it--that is not a good solution when attempting to install complex packages with many dependancies. Using CPAN for example.

Presumably, as the 'manifest' target is being produced by (most?) makefile.pls, the correct place to fix this is somewhere inside the EU::MM stuff. Does anyone have any cluebats as to how to go about this?

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re: A permanent fix for the Windows 'manifest' issue?
by Corion (Patriarch) on Mar 23, 2009 at 15:13 UTC

    The latest (at this time) release of ExtUtils::MakeMaker, v6.50, claims in its Changes that some provision was made to address the generation of manifest files for DLLs. I'm not sure whether using the latest version addresses the problem, but if so, listing ExtUtils::MakeMaker 6.50 as a prerequisite to your module (in Makefile.PL) should make the issue go away.

[reply]
[d/l]

      Hm. Attempting CPAN install ExtUtils::MakeMaker sees it pulling and installing v6.48. Which is up from the v6.42_01 that I had, but...it still fails to build XS modules in the same way, for the same reason.

      So I tried: 

      cpan> install ExtUtils-MakeMaker-6.50
Warning: Cannot install ExtUtils-MakeMaker-6.50, don't know what it is
+.
Try the command

    i /ExtUtils-MakeMaker-6.50/

to find objects with matching identifiers.

      [download]

      Is there a special incantation to force CPAN to fetch the latest greatest version?

      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.
[reply]
[d/l]
[select]

        It was uploaded yesterday and hasn't replicated to your CPAN mirror yet.

        Or maybe you're using a cached module listing. Try reload index

        Or you could try adding mirror ftp://mirror.csclub.uwaterloo.ca/pub/CPAN/. It has it.

        You can always download the archive and installing it without using cpan. 

        perl Makefile.PL
nmake
nmake test
nmake install

        [download]

        (s/nmake/dmake/ for Strawberry Perl?)

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom