Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

by Intrepid (Deacon)
on Jan 17, 2008 at 11:33 UTC ( #662848=note: print w/ replies, xml ) Need Help??


in reply to Re: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
in thread UnBefuzzling XML::Parser: an adventure with EU::MM method overrides

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!


Comment on Re^2: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
Re^3: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
by syphilis (Canon) 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
      In reply to our monk Rob, who wrote again on Jan 17, 2008 (in node 662856) (just can't shut this bloke up eh! ^_^):
      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). [...] 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

      The Makefile.PL tells the whole story, Rob. The maintainer has made it presently die() if the arguments to perl Makefile.PL do not include EXPATLIBPATH=some valid path EXPATINCPATH=some valid path, or there is not a (now old, not current) specific installation of libexpat devel files. The maintainer could have made it simply warn(); IMHO that would have been a better choice. No matter, we are so done with all that now. A much more powerful approach to locating the library file is the core functionality added by my coding effort on this. The gcc compiler is actually being given a chance to find the file (such as something named libexpat.a) and then Perl (EUMM) gets told about that. That's the magic of using the hints/* mechanism instead of merely twiddling around with Makefile.PL.

      I have to mention, Rob, that it's now clear that you probably didn't have a look at the "required reading" mentioned near the start of the root node in this discussion. Tsk tsk ;-P

      So, anyway, XML::Parser won't install via CPAN.pm on MS Windows even if the devel files needed are located where your gcc can find them, or even if installed where Perl can find them (unless you comply with that other very obscure requirement just mentioned, about a very specific install for a libexpat that is old) ... as you note below:

      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.

      You can do something about that by simply editing your Perl Config.pm file so that the hash element libpth has the Windows-mode pathname that corresponds to /usr/local/lib under MSYS. One time effort.

      It's the $Config{libpth} string of space-separated paths that EUMM uses to search for libraries. If you make the libpth match the gcc installation's notion of where libraries are kept, it won't matter whether you are on *nix or anything else. Things will tend to work rather more smoothly. That's all as an aside just to be helpful, however. It's not a general solution for all users.

      As an addendum to the above

      The places searched by Perl (EUMM) for compiled C libraries are set by the libpth as noted above. To quickly check what those are, one can do something like

      perl -MConfig -le 'print for grep { -d } (split /\s+/, $Config{libpth} +)' # *nix shell perl -MConfig -le "print for grep { -d } (split /\s+/, $Config{libpth} +)" # ms windwoes cmd

      I recently went through the process of compiling Perl from source again, and noticed that the variables loclibpth and loclibpth are described as being lists of directories that Perl will search for "local" libraries and headers respectively, ahead of those listed in libpth. It is possible (but at this time I haven't tested) that modifying these vars in Config_heavy.pl would provide benefits when trying to install the kind of Perl extensions we are discussing. One would query those in the same manner as the above:

      perl -MConfig -le 'print q|LIBS:|;' \ -e 'print for grep { -d } (split /\s+/, $Config{loclibpth});'\ -e 'print q|INCLUDES:|;'\ -e 'print for grep { -d } (split /\s+/, $Config{locincpth});' # Output on one Ubuntu GNU/Linux box was: # LIBS: # /usr/local/lib # INCLUDES: # /usr/local/include

      HTH, y gracias

Re^3: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
by Anonymous Monk on Feb 25, 2009 at 18:47 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://662848]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2014-09-20 12:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (159 votes), past polls