So after about 2 solid days troubleshooting my Crypt::SSLeay problems here are some things that I learned that I hope can help someone else.
1. when using pp the -v 9 switch is helpfull to see what dll files are being packed. 2. On Winblows boxen www.sysinternals.com has a nice little utility called NTFileMon, which is like lsof for windows. 3. http://www.dependencywalker.com/ is a neet little tool in windows that will show you what dll files a particular .exe will need, though it didn't help me find my problem. The problem: figuring out why exactly having perl58.dll from activstate's build 804 in my current working directory would cause Crypt::SSLeay to fail, and not anything else in my package. My solution (if there is a better one please chime in) was to build the exe, copy my lib directory from my perl install into my working directory, and watch NTFileMon to see what files my exe was looking for. I tried gdb, but it was 0 help. From there I deleted directories, and added -M switches to narrow down which module exactly was causing the problem. -M Net::HTTPS -M LWP -M LWP::Protocol::https is what worked. I'm not 100% sure that this was the only problem, as I recompiled the module (i was using a precompiled ppd) using mingw and dmake. I guess this was more of a problem with ScanDeps, I know very little about C and shared object loading, though I learned alot troubleshooting this. Autrijus is there a possible way to put some sort of debugging wrapper on a pp compiled executable that could perhaps throw "Module $Module not found", or "Shared Lib $so not found"? output from scandeps had LWP::Protocol::https10 but no LWP::Protocol::https, I have no idea why they are both in there but https was not found.
