".dll files can't change names" That's partially true. You can change the names of xs module dlls because they are directly loaded. The problem is any bundled dlls they reference (e.g. ssleay32.dll) are indirectly loaded by the system. Those dlls must have the original name, and must be found in the executable directory or on the path.
So, I think we're back to the suggestion of unpacking all files into the normal lib structure with their original names. Dependent libraries should be unpacked with their original names at the top of the tree and that directory should be added to the library search path. --Scott -----Original Message----- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Saturday, May 31, 2008 5:34 AM To: Paul Miller Cc: par@perl.org Subject: Re: problem with POSIX package and par On Fri, May 30, 2008 at 2:46 PM, Paul Miller <[EMAIL PROTECTED]> wrote: > On Fri, May 30, 2008 at 02:15:51PM +0200, Roderich Schupp wrote: >> Do the Gtk2 modules use some non-standard procedure >> to dynamically load their shared glue libraries >> that foils PAR's intercept? > > No, standard. I think the way PAR packs .so files is OK. But in > win32, the .dll files can't change names. I learned about this > business here: > > http://www.nntp.perl.org/group/perl.par/2006/09/msg2506.html That particular message doesn't contain any facts concerning the problem. I read the whole thread and the bug tracker at rt.cpan.org, but failed to see any explanation what is really going on here, only discussion of crufty workarounds. Anyway, this thread may be moot, as Audrey clearly states a tracker entry that certain failures wrt intercepting DynaLoader have been fixed in PAR 0.952. "...in win32, the .dll files can't change names" is definitely wrong, as the hash-renaming definitely works for all core Perl modules (with shared library parts). The Gtk Perl bindings (and apparently similar things like the Wx bindings) must do something different from the average XS module. Could be something like (spoken in Linux terms) Gtk2.so (the glue shared library for gtk2+) statically referencing (on the shared library level) Glib.so (the glue library for glib)... nope, at least not on Linux Or Gtk2.so dynamically dlopening Glib.so... nope either. Hmmm... I'll try to investigate on Windows using the Syinternals tools tonite. Cheers, Roderich > > It is my understanding that any module that loads the dlls from > another package will fail in some way because of the hash > renaming. This new POSIX problem leads me to believe it happens > under simpler circumstances as well. > > On Fri, May 30, 2008 at 11:14:29AM +0200, Steffen Mueller wrote: >> > I was able to get PAR to work with Gtk2-perl by extracting all >> > the packed modules into a non-renamed lib dir and then filtering >> > PAR's @INC subs out of the stack. >> >> What a gruesome thing to do :/ > > Yes it really is. I wrote a module to do it for me, but I'm not > necessarily proud of it. > > http://voltar.org/grm/#gtk2-perl-PAR > > I'm excited by your openness to changing the way the unpacker > works. I assumed there was some really important reason for > doing it -- like collisions or something. > > My kludge unpacker makes a separate directory for each par in the > executable. I imagined that would resolve conflicts. > > Eh. > > -Paul > > -- > If riding in an airplane is flying, then riding in a boat is swimming. > 85 jumps, 36.0 minutes of freefall, 69.1 freefall miles. >
