Re: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides

The dlltool conundrum ...

Given that dlltool always runs flawlessly, I'm not sure that doing away with it should be highly prioritised. Then again, if dlltool is as anachronistic as you say (and I don't doubt you), then it's hard to argue against replacing it with something more contemporary.

I don't have the expat library in a place where it's found by default, so I ran your XML-Parser distro by starting with perl Makefile.PL INC="-IC:/_32/msys/1.0/local/include" LIBS="-LC:/_32/msys/1.0/local/lib -lexpat" and that all works fine on Strawberry Perl (5.10). But doing the same on my own MinGW-built perl 5.10, all of the tests fail (during 'dmake test') because Can't find 'boot_XML__Parser__Expat' symbol in C:\_32\comp\XML-Parser-2.36_04\blib\arch/auto/XML/Parser/Expat/Expat.dll .

I don't know why such a discrepancy arises. The CPAN version of XML-Parser-2.36 builds fine on *both* of those aforementioned builds of perl. I use different versions of dmake when building modules for those 2 builds of perl - but I doubt that's the reason. More likely some difference in EU::MM, I suspect. (It's a little intriguing ... but not nearly enough to make me go diving into the sources :-)

Cheers,
Rob

Comment on Re: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides Select or Download Code

Replies are listed 'Best First'.
Re^2: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides by Intrepid (Curate) on Jan 17, 2008 at 11:33 UTC
Great scott, another reply! ;-) On Jan 17, 2008 our monk Rob told me (in #662812): I don't have the expat library in a place where it's found by default, so I ran your XML-Parser distro by starting with `perl Makefile.PL INC="-IC:/_32/msys/1.0/local/include" LIBS="-LC:/_32/msys/1.0/local/lib -lexpat"` and that all works fine on Strawberry Perl (5.10). But doing the same on my own MinGW-built perl 5.10, all of the tests fail (during 'dmake test') because `Can't find 'boot_XML__Parser__Expat' symbol in C:\_32\comp\XML-Parser-2.36_04\blib\arch/auto/XML/Parser/Expat/Expat.dll`. I don't know why such a discrepancy arises. The CPAN version of XML-Parser-2.36 builds fine on both of those aforementioned builds of perl. I use different versions of dmake when building modules for those 2 builds of perl - but I doubt that's the reason. More likely some difference in EU::MM, I suspect. I suspect you're right about that. I can say this much about the failure: it is due to the way the DLL was made, i.e. the way gcc was invoked. I know this because it was the last flaw I found when I was writing the build support changes; it is the lack of the flag `--export-all-symbols` that causes this. The DLL that gets built (`blib/arch/auto/XML/Parser/Expat/Expat.dll`) doesn't have any symbols from the object file built by the previous command because they are not marked for export in any way. As to what could be interfering on your home-built Perl-5.10 installation, I don't know, but I would be happy as a barnacle by the bay if at some point we could figure it out, since I want this strategy to be as robust as possible. It could help if you might be able to confirm the complete command line that is being run in the linking step that creates the DLL, so that we can confirm my diagnosis about `--export-all-symbols`, by running the build attempt again and capturing the console output. Just other one point to get clarified right now (I'm going to separately mention your wise point about not removing the `dlltool` stuff if its working consistently in another note): you mentioned that "the CPAN release of XML-Parser-2.36 builds fine on both machines"; but it cannot be automatically built and installed using cpan, eh (the only way to build-test-install it is with the manual addition of commandline arguments)? Gracias! Soren A / somian / perlspinr / Intrepid	[reply]
Re^3: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides by syphilis (Archbishop) on Jan 17, 2008 at 12:38 UTC
but it cannot be automatically built and installed using cpan That's a valid indictment of the way CPAN.pm works. It's not just XML::Parser that's subjected to this ... if I understand correctly, any module that needs to be built against a 3rd party library cannot be built using CPAN.pm iff the 3rd party library is in a location where perl is unable to find it (by default). On nix, this is generally not a problem as the 3rd party libraries are normally installed in a location where perl does* find them by default. But on Windows I, for one, build my 3rd party libraries using the MSYS shell, and install them into (what the MSYS shell regards as) /usr/local ... and perl does not find that "/usr/local" directory by default. Actually, I think (based upon some recent private correspondence from adamk) that XML::Parser is a little special in that, even if the expat library is placed in a location where perl can find it by default, XML::Parser still won't build on Windows using CPAN.pm ... but complain about that to the XML::Parser author. I'm sure CPAN.pm is very good, but I personally find it detestable (primarily because it ignores any instructions that have been given in the README) and don't use it. I tend therefore to also avoid modules such as Net::SSH::Perl which assume (via their copious use of other modules) that CPAN.pm is being deployed. In short, since I don't use CPAN.pm (and since I'm not the author of XML::Parser) I don't really care about the caviats regarding the building of XML::Parser on Windows using CPAN.pm. I've personally found the building of XML::Parser to be quite straightforward (once I knew how :-) However, I probably will get back to looking at why that disparity exists between Strawberry Perl and my own MinGW-built perl when building your patched XML-Parser-2.36. Curiosity is sure to get the better of me in the end :-) Cheers, Rob	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^3: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides by Anonymous Monk on Feb 25, 2009 at 18:47 UTC
of course, I have no idea if this is the right place to ask this, but I'm desperate to ask it some where! just the usual storory... I am working in Mac OS10.5, and installing packages from cvs using fink. Can someone here tell me what is causing the following error? tdoak@129-79-233-163:~$ hawkeye (02-25 13:29) Can't find 'boot_XML__Parser__Expat' symbol in /usr/local/amos-2.0.8/lib/libExpa t.dylib at /usr/local/amos-2.0.8/lib/XML/Parser.pm line 14 Compilation failed in require at /usr/local/amos-2.0.8/lib/XML/Parser.pm line 14 . BEGIN failed--compilation aborted at /usr/local/amos-2.0.8/lib/XML/Parser.pm lin e 18. Let's just say that I've been banging my poor head on this for days now. Cheers, Tom	[reply]