If you want to use a DLL that does not come with Windows, the best approach is to copy it into the same directory where perl.exe lives. That way, Win32::API, Windows and perl.exe will be able to find it.
| [reply]
[d/l]
[select] |
The problem is i need to roll out this "module" on X machines. Is it possible to handle this with ppd?
I wont be able to log on to every machine and place a copy of the dll in the perl directory.
Thanks for your help and fast reply ...
| [reply] |
Personally, I would leave distribution of files to whatever mechanism is in place for administrating the machines you have, but I understand that this is not always possible.
I don't use PPD, so I don't know how it specifies files that should go into the bin directory of the Perl distribution.
From reading some documentation on LoadLibrary, Windows also looks in the current directory to load a DLL, so you could change to the directory and then try to load the DLL through Win32::API. I haven't tried that myself.
If all else fails, you have to look how DynaLoader does its magic on Win32.
| [reply]
[d/l] |
Is it possible to handle this with ppd?
Yes - for an example of how this is usually done see the ppd file for Crypt::SSLeay at http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd. Note the <INSTALL EXEC .... </INSTALL> command and the install script that it calls (which installs the 2 SSL dll's) at http://theoryx5.uwinnipeg.ca/ppms/scripts/install_ssl.
Another alternative to that is to place the dll in the blib/script directory of the ppm binary - in which case the dll will automatically be placed in perl/site/bin (unless there are permissions issues which forbid it).
Update: Actually, it might go into perl/bin, not perl/site/bin ... not sure offhand.
Cheers,
Rob
| [reply]
[d/l] |