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.
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
In reply to Re^4: UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
by Intrepid
in thread UnBefuzzling XML::Parser: an adventure with EU::MM method overrides
by Intrepid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |