Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

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

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

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

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 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 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

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 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 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 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

Replies are listed 'Best First'.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://662868]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2018-06-23 03:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.