Re^10: XML::LibXML on 64-bit Windows (solved)

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

Comment on Re^10: XML::LibXML on 64-bit Windows (solved) Select or Download Code

Replies are listed 'Best First'.
Re^11: XML::LibXML on 64-bit Windows (solved) by John M. Dlugosz (Monsignor) on May 11, 2009 at 16:11 UTC
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]
Re^12: XML::LibXML on 64-bit Windows (solved) by syphilis (Archbishop) on May 12, 2009 at 10:42 UTC
Ah, so it notices what's on your PATH, INCLUDE, and LIB, and deduces which compiler-specific settings to use based on that? Yep - that's about it. SetEnv.cmd sets up the path to 'nmake', 'cl' and 'link' - and it also sets the lib and include env vars to point to the standard headers and libs. Then it's just a matter of adding the appropriate locations to path, lib and include so that the libxml2, libiconv and zlib stuff also gets found. Does that mean you have a working module you can share? Yes. Binary? or a CPAN packaging that will "make" cleanly on this platform? I could provide either binary or source. The source builds cleanly if you manually run 'perl Makefile.PL', 'nmake test' and 'nmake install' (assuming your LIB, INCLUDE and PATH env vars are set appropriately). I expect it builds ok using the automated CPAN procedure, too ... but that remains untested. would one have to avoid calling Reader()? No - I've just built (the latest) libxml2-2.7.3 using "the same compiler" (ie using the Platform SDK for Windows Server 2003 R2 compiler), and that fixes the problem with Reader() as expected. I don't have any webspace to upload this stuff to - so I'd have to email it (which doesn't bother me). However, if you have the SDK compiler, building everything yourself is no big deal. Building libxml2-2.7.3 was fairly straight forward - the instructions are in win32/Readme.txt. The only additional thing I had to do that's not mentioned in the Readme.txt was: 1) Create a copy of libiconv.lib named iconv.lib; 2) In win32/Makefile.msvc, change `LIBS = $(LIBS) kernel32.lib to: LIBS = $(LIBS) kernel32.lib bufferoverflowU.lib` [download] When it came to installing the library with `nmake /f Makefile.msvc install`, the process terminated with an error - but everything needed got installed ok anyway. To be properly thorough, I ought to rebuild zlib and iconv using my SDK compiler (which would get rid of the msvcr80.dll dependency completely), but everything sems to be working fine without going to those lengths - all tests are passing. Let me know how you want to proceed Cheers, Rob	[reply] [d/l] [select]