On Nov 27, 2007 11:05 PM, Scott Stanton <[EMAIL PROTECTED]> wrote: > > > Steffen Mueller wrote: > > > That's actually a good idea: Avoiding dll file name clashes using a > > directory for each external (non-perl-module) dll. Currently, we > extract > > the external dlls under their original name, IIRC. However, I don't > know > > how you can make those directories accessible to the dll loader > without > > appending *each* directory to $PATH. Doing that in a long path ($TEMP > is > > long on Windows, isn't it?) might quickly result in hitting the length > > limitations of env. vars on Windows. > > Long paths might be an issue, although if we're talking just a handful > of libraries, in practice it might work just fine.
Putting every dll into its own directory won't solve the name clash issue: no matter how you order this LD_LIBRARY_PATH (or whatever it is called), if there are two dlls with the same name any attempt to load such a dll will only get the first along the library search path. So you might as well put them all with their original names into one directory (and have PAR::Packer carp if it encounters a name clash). If two dlls with the same name ever worked in the unpacked case, then this means that either (1) the native OS library loader or (2) the application explicitly deviates from this simple model of operation: search the (fixed at program startup) library path until a dll with the required name is found. Cheers, Roderich
