mt -nologo -manifest libxml2.dll.manifest -outputresource:libxml2.dll;
+2
[download]

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

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