in reply to Re^7: XML::LibXML on 64-bit Windows (solved)
in thread XML::LibXML on 64-bit Windows

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

Replies are listed 'Best First'.
Re^9: XML::LibXML on 64-bit Windows (solved)
by John M. Dlugosz (Monsignor) on May 08, 2009 at 16:02 UTC
    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'
    Probably because C doesn't have inline. Perhaps a compiler switch is needed to enable C99 mode, or at least those features that the compiler can do anyway because they are in C++.

    I can't find any such options in the online help. But, using __inline should do the trick. Or, use optimization flags that tell it to inline whatever it feels like. That would be /Ob2, which is included in any of /O1, /O2, or /Ox (size, speed, full, respectively).

    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.
    Such is my experience. I remember looking at the RTL source code, and finding that the default heap behavior was being changed during start-up. If they had left it alone, it would have worked just fine. There is a "per process" heap created by Win32 for that very reason. The RTL startup code created a fresh heap and pointed the handle (used by malloc etc.) at that one.

    You make a good point about XS in general. Which behavior can it generate that causes memory to be allocated/freed using the normal C routines? That should cause warnings at the very least.

    I found the "PlatformSDK for Windows Server 2003 R2" and installed it without any problem. Since you've gotten this far, shoulnd't it be a matter of using the command shell for that set-up and re-running the installer that you already fixed? Or is there still manual work involved?

    I recall other discussions saying that the PlatformSDK compiler uses the same simple runtime DLL as Windows itself and the bundled apps. I would suppose that this uses the Process Heap.

    Hmm, I looked at the crt source for that, and it's exactly the same as the 8.0 one. It creates its own Win32 Heap at first use. So, if this does link to the same MSVCRT.DLL that is already in Windows, using GetProcessHeap still won't help. The variable _crtheap is not exported.

    You could use GetProcessHeaps, which returns handles to all the heaps that are valid for the process. If there is more than one for some reason, you would still have to determine which is the right one that is used by malloc/free. Oh why couldn't they just have used GetProcessHeap instead of HeapCreate?

    I think you'd better use the same compiler, or expose malloc/free functions from the Perl DLL that all xs code is required to use. I'm surprised it doesn't do that already.

    —John

[reply]
[d/l]
[select]
      But, using __inline should do the trick

      In 1.69_2 they've simply dropped the "inline" - which is what I did. That still doesn't mean it's right, but.
      Interestingly, according to comments in 'perl-libxml-mm.c', they've dropped the "inline" because AIX doesn't like it, not because Microsoft Compilers don't like it.

      I found the "PlatformSDK for Windows Server 2003 R2" and installed it without any problem

      To use that compiler you just need to set up the environment, which you do by running: 
      C:\path\to\SetEnv.cmd /XP64 /RETAIL

      [download]
      (That's the equivalent of running vcvars32.bat with Visual Studio.) With that done, the Platform SDK compiler should be automatically found.

      I think you'd better use the same compiler

      Yeah ... that's the way it *should* be done, but with many extensions it's not necessary. Afaict, with XML::LibXML, it's only necessary if you're going to want to call new XML::LibXML::Reader(). Note that this problem of mixing runtimes is not a Windows bug, or a C runtime bug, or a compiler bug - it's a "user" bug. That is, it's a case of the "user" (me) doing something that he (I) oughtn't be doing. And there's only *one* way to fix this problem - namely avoid using more than one runtime (or, iow, "use the same compiler").

      Cheers,
      Rob
[reply]
[d/l]
[select]
        Ah, so it notices what's on your PATH, INCLUDE, and LIB, and deduces which compiler-specific settings to use based on that?

        Perhaps the inline thing was supposed to be a macro on Microsoft and other compilers, but AIX's headers didn't respect its use as a reserved word so bad things happened when it was #define'd as something that was an implementation-specific reserved keyword or phrase.

        You said solved. Does that mean you have a working module you can share? Binary? or a CPAN packaging that will "make" cleanly on this platform? If the former, did you recompile with the matching compiler, or would one have to avoid calling Reader()?

        —John

[reply]
[d/l]

In Section Seekers of Perl Wisdom