> OK, when I do demo that way, it works. But I get two copies of the IM > dlls stored in the demo.exe archive, which makes it roughly 3MB bigger > than it should be. Do you get two copies in your demo.exe? And or what > is the size of your demo.exe? Mine is 4,694,818 with one copy (which > doesn't work and doesn't get extracted), and 7,528,502 with two copies > (which does work, and at least one of which gets extracted to the > PAR_TEMP directory. > > Of course, running demo.exe successfully at "super" size makes the > inability to do so for my other programs more mysterious... because they > worked fine with PAR 0.85. Maybe I didn't do something right when I > added the option (but the double libraries happened, so ???). Lemme try > that again... using your option, pasted... > > ... > > OK, I did it your way, but then changed from -l to --link, and it all > works. But there are two copies of all the libraries in the archive. > Your other response indicates that that might be a bug that is now > understood? And might get fixed in PAR 0.91? Or maybe even via a > sooner patch? >
Well, it only a bug if you "abuse" the --link option by giving it a directory name. It wasn't planned to accept dirs, only files as the docs say. It was only thru laziness that I even tried it with a dir. But a patch might make it a feature without the duplication bug... > Not sure what I did wrong last time, when I tried --link on my own. > > I'm still not sure why I should have to specify a --link option at all, > when the .dlls are a necessary part of an included module: that also > sounds like a bug to me. > PAR has no way of knowing that Magick.dll uses the other dlls. The only reference to them is inside the binary. PAR just packs up everything in the same dir as a dll that would be located and loaded directly by Dynaloader (like Magick.pm loads Magick.dll). In a non-PAR app, Windows finds the other dlls on the same path that Magick.dll loaded from. That's not a Perl function. The problem comes when running with --clean. Then there is no inc\ dir extracted (for unzip speed and footprint) so dlls like Magick.dll have to be extracted to $PAR_TEMP. Then Windows has no way of getting the other dlls out of the PAR zip, so --link identifies dlls that need to go into shlib\ and then to $PAR_TEMP where Windows can find them. The --link option began life to suppport shared libs that were outside of the module dir. Perhaps dlls that are inside the module dir could be automatically moved to shlib\ or something.... Alan
