in reply to Re^4: XML::LibXML on 64-bit Windows
in thread XML::LibXML on 64-bit Windows

Using those binaries (for libxml2 and libiconv), I started with building the pre-requisite XML-LibXML-Common-0.13. I can build it ok, but 'nmake test' throws up a nasty little runtime showstopper: 
C:\_32\comp\XML-LibXML-Common-0.13>nmake test

Microsoft (R) Program Maintenance Utility   Version 7.00.8882
Copyright (C) Microsoft Corp 1988-2000. All rights reserved.

        C:\_64\perl1004\bin\perl.exe "-Iblib\lib" "-Iblib\arch" test.p
+l
1..8
# Running under perl version 5.010000 for MSWin32
# Win32::BuildNumber 1004
# Current time local: Thu May  7 11:28:37 2009
# Current time GMT:   Thu May  7 01:28:37 2009
# Using Test.pm version 1.25
Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XM
+L::LibXML:
:Common: load_file:A dynamic link library (DLL) initialization routine
+ failed at
 C:/_64/perl1004/lib/DynaLoader.pm line 202.
 at test.pl line 10
Compilation failed in require at test.pl line 10.
BEGIN failed--compilation aborted at test.pl line 10.
NMAKE : fatal error U1077: 'C:\_64\perl1004\bin\perl.exe' : return cod
+e '0x22'
Stop.

[download]
I'm still trying to find/work out what needs to be done about that. There's an accompanying pop-up telling me that a runtime error (R6034) has occurred, and "an application has made an attempt to load the C runtime library incorrectly". Googling suggests that it might be something to do with that fucking half-arsed "manifest" puke that the peabrains at Redmond dreamt up. (I don't have VC 8, though I do have the msvcr80.dll.)

In order to build, I unzipped those xml2 and iconv binaries into C:\_64\x64_lib, then, having already set up the environment for the SDK compiler, I ran: 
set INCLUDE=%INCLUDE%;C:\_64\x64_lib\include
set LIB=%LIB%;C:\_64\x64_lib\lib
set PATH=%PATH%;C:\_64\x64_lib\bin

[download]
Then I threw the Makefile.PL that ships with XML-LibXML-Common to the shithouse, and replaced it with: 
use ExtUtils::MakeMaker;

WriteMakefile(
    'NAME'        => 'XML::LibXML::Common',
    'VERSION_FROM'    => 'Common.pm', # finds $VERSION
    'AUTHOR'        => 'Christian Glahn <christian.glahn@uibk.ac.at>',
    'ABSTRACT'      => 'Routines and Constants common for XML::LibXML 
+and XML::GDOME',
    'LIBS' => '-lxml2',
);

[download]
Then ran 'perl Makefile.PL' and 'nmake test'. If we can get past that runtime error it should be fine - and we can proceed to building the other modules.

Cheers,
Rob

Replies are listed 'Best First'.
Re^6: XML::LibXML on 64-bit Windows
by John M. Dlugosz (Monsignor) on May 07, 2009 at 16:35 UTC
    You can't just "have" the msvcr80.dll, or one of them with that same name. You have to install the redistributables. It puts several versions, different 32 and 64 bit files, into its SxS cache.
[reply]
      Well ... at least I've got XML-LibXML-Common-0.13 built and working fine. Turns out I just had to embed libxml2.dll.manifest (which was in the package's 'lib' folder) into libxml2.dll - which I did by moving the manifest to the 'bin' folder, cd'ing to that folder, and running: 
      mt -nologo -manifest libxml2.dll.manifest -outputresource:libxml2.dll;
+2

      [download]
      Thanks jand, for pointing out to me that it was the xml2 and iconv dll's that needed the embedded manifest. (For some reason, the iconv dll was ok - perhaps the manifest was already embedded in it.)

      Now, I spose I might as well try and build the other dependencies and XML::LibXML itself, just to verify that it can be done.

      I'll report back later (for the benefit of the thousands of people who are intently following this thread ;-)

      Cheers,
      Rob
[reply]
[d/l]
        Now, I spose I might as well try and build the other dependencies and XML::LibXML itself

        Both XML::NamespaceSupport and XML::SAX build and test fine. They're pure perl, so no dramas there.

        XML::LibXML needs zlib, so I installed that from the location that John provided earlier. Then I can build XML-LibXML-1.66 without any dramas (straight out of the box), though 2 tests fail. Firstly, test 11 of t/16docnodes.t: 
        not ok 11
# Test 11 got: "<test contents=\"\xE4\"/>" (t/16docnodes.t at line 57)
#    Expected: "<test contents=\"\xC3\xA4\"/>"
#  t/16docnodes.t line 57 is:         ok( $node->serialize(), encodeTo
+UTF8( 'iso-8859-1',

        [download]
        And, in t/40reader.t, after the first block of 48 tests are run, a segfault-type error occurs. (It seems to be the clean-up that occurs when exiting the block that causes the crash.)

        Other than that, 1.66 seems fine.

        The same goes for (the latest) XML-LibXML-1.69, except that that in order to get it to build I have to delete the one occurrence of the word "inline" in perl-libxml-mm.c. That is, in perl-libxml-mm.c, there's a function declared as 'static inline void', and I had to change that declaration to 'static void'. I don't know if that's the correct fix.

        UPDATE: Just tried version 1.69_2. Builds straight out of the box, but 40reader.t still segfaults on exiting the first block of 48 tests. No other problems.
        UPDATE 2: The failure with 40reader.t has nothing to do with exiting a block of code. It results from this line of code: 
        my $reader = new XML::LibXML::Reader($how => $fd, URI => $file);

        [download]
        $fd is a filehandle, and I think I've run afoul of using multiple runtimes (ie msvcr80.dll and whatever runtime my x64 build of perl uses). If the filehandle is allocated by one dll, the other dll won't know nothing about it - and will throw a tizzy when the filehandle gets passed over to it. Building libxml2 using my "PlatformSDK for Windows Server 2003 R2" compiler should fix the problem. (Not sure if I want to go to that trouble, but.)

        Cheers,
        Rob
[reply]
[d/l]
[select]
Re^6: XML::LibXML on 64-bit Windows
by Anonymous Monk on May 07, 2009 at 03:07 UTC
    Maybe just copy libxml2.dll.manifest to the same directory as libxml2.dll?
[reply]
      Maybe just copy libxml2.dll.manifest to the same directory as libxml2.dll?

      I don't have any '.manifest' files to copy - at least none that I can find.

      I think it's actually a Common.dll.manifest that's needed (or a manifest embedded into Common.dll), but I have no clue how to go about dealing with this issue. Apparently there's an mt.exe command I can run, but I don't know what it is and the mt /? documentation doesn't provide any output that I can understand.

      I've tried updating to EU-MM-6.50, but that doesn't help, and I've checked out some recent threads on perlmonks that deal with the problem (which also haven't given me the solution). Not to worry ... it'll turn up eventually.

      Cheers,
      Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom