The intent isn't to avoid name clashes within a single application, it's to avoid version clashes across applications with a shared cache directory. Instead of creating a separate cache-<sum> directory for every application, you can share a single cache directory as long as files are given reasonably unique names. With an md5 sum, you can be pretty confident that you won't have name collisions for .pm files, but for secondary .dll files, you can't change the name. The solution is to put them in uniquely named subdirectories. This also allows subsequent releases of one application to contain updated versions of the same library without problems.
The general problem I'm concerned with is how much /tmp space a collection of par apps end up consuming. If you multiply the unpacked size by the number of distinct applications and the number of users of the system, you very quickly run out of space in /tmp. When I was using perlapp, I didn't have this problem because all of the apps shared a common cache per user. The vast majority of the unpacked files can be shared without a problem. For now, I have to use --clean to avoid the problem, but this is slower than I'd like. --Scott -----Original Message----- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 12:42 AM To: Scott Stanton Cc: Steffen Mueller; [email protected] Subject: Re: Improving speed of par app startup 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
