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

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

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

Replies are listed 'Best First'.
Re^10: XML::LibXML on 64-bit Windows (solved) by syphilis (Archbishop) on May 09, 2009 at 13:50 UTC
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]
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]