Bug #13508 for PAR: cannot find Glib.dll on win32, despite being packaged in the exe

On Thu, Aug 31, 2006 at 07:29:05AM -0400, Steffen Müller via RT <bug-PAR@rt.cpan.org> wrote: Show quoted text
I am not packaging *additional shared libraries*, I am packaging a perl module. Glib.dll is the perl inetrface to libglib. Also, Glib.dll *is* being packaged automatically by par, the problem is that par renames it to some gibberish file (as I already explained). -l is certainly not going to help as PAR does not load Glib.dll but its own renamed version of it. packaging Glib.dll in addition will clash with the version par itself packaged. This is a bug in par, and cannot be solved with commandline switches. Show quoted text
Yeah, and on top of that thanks for completely ignoring my bug report and simply closing it without reading it and cetrainly without resolving it :/ If you don't understand something, feel free to aks. But please don't just blindly close completely valid und unresolved bugs! -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

On Do. 31. Aug. 2006, 15:14:05, schmorp@schmorp.de wrote: Show quoted text
Right. Sorry, I missed that. Show quoted text
FYI, that's because the dlls for various dependencies might clash. Show quoted text
Certainly... Have you tried? -l makes sure the name is retained because some dlls use other dlls and PAR can't intercept and mangle the name. Show quoted text
Possibly. Or: http://mail.gnome.org/archives/gtk-perl-list/2005-April/msg00187.html Now, I know there is a difference between what that guy had problems with (gtk+) and what you have problems with (Glib.dll as part of a CPAN module). Show quoted text
Dare accuse me of not reading things and ignorance. Misreading is a different thing. And usually an honest mistake. Which was the case here. Show quoted text
Which are readily reopened by a reply. If I ask (which you suggested I do) and you answer, the ticket's reopened. If you don't answer, a ticket which I can't work on without the answer isn't valid. Now, no, I didn't ask. But that's the reason I got into the habit of not waiting for a reply before closing old tickets. (And the same logic readily applies if I wrongfully think the problem should be solved with command line options.) On an unrelated note, if you are so inclined, retry using PAR 0.952 which might have a slightly different way of handling dlls. When answering, always keep in mind that the one you are answering to is also working on this in his spare time, so let's keep the tone down. Thank you.

2006/9/1, Marc Lehmann via RT <bug-PAR@rt.cpan.org>: Show quoted text
Hi Marc! First, I've send you a commit bit for http://svn.openfoundry.org/par/. :-) Show quoted text
In fact, the Glib.dll problem (DynaLoader-specific name mangling defeats third-party shared object loading) is the same as the Wx.dll problem we diagnosed and resolved on PAR 0.952, so there's a high probability that it's already resolved. If not, please send me a one-liner that exhibits the problem (pp -e "..."); I'm quite willing to investigate some more. If you'd like to trace it, the logic is in PAR.pm line 671 as of PAR 0.952. Thanks! Audrey

On Tue, Oct 03, 2006 at 05:35:30AM -0400, Glenn Linderman via RT <bug-PAR@rt.cpan.org> wrote: Show quoted text
Well, according to Audrey, there should not be any problem left - I unfortunately still did not have time to recheck this with current versions of PAR, so all I can offer is my (supposedly) outdated solution. Please note that the real problemc ame from the fact that PAR renamed dll's so they couldn't be found anymore. Show quoted text
Yes. Show quoted text
The problem arose on windows just because we package gtk+ only there. On windows, gtk+ doesn't use absolute paths so there is no problem. On unix, the problem is immense, as you would have to rewrite lots of config files with absolute paths in them, something I didn't try yet. Show quoted text
This is what I do (slightly simplified, I actually wrote down every single .dll file manually to exclude the ones not required) to call pp on windows: http://data.plan9.de/ppwin As you can see, I simply package all Gtk2 and Glib-related files and libraries manually, which works just fine. In the binary, I do this at the very beginning: http://txt.schmorp.de/2629b6fdba568e7cda3ed953cbaf8613.txt This first checks wether par is running (I found no good/official/documented way to do this, so take this with a grain of salt). Then I remove all paths from @INC except the one from PAR (because otherwise perl would try to find dlls at places where it was originally compiled, not where it is run, and there might be a completely incompatible version of perl installed there, we rtan into that problem). This, again, is not documented or official, so future versions of par might break, Then I extract additional files packaged under /root, this is where I put my own data files and stuff. Again this uses undocumented functionality (PAR_TEMP) that might not work in future versions. I do not use @INC in _that_ project, but I have another win32 project using par, where I do: unshift @INC, $ENV{PAR_TEMP}; in the BEGIN block and: unshift @INC, $ENV{PAR_TEMP} if %PAR::LibCache; _directly_ after it, as PAR removes my handler again (just like renaming dlls, I never found out why it acts this irrationally, and the only thing that kept me from writing my own wrapper was that I thought it had to be possible - it cost me two days to work around par :). -- The choice of a -----==- _GNU_ ----==-- _ generation Marc Lehmann ---==---(_)__ __ ____ __ pcg@goof.com --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE

On approximately 10/3/2006 4:58 PM, came the following characters from the keyboard of Glenn Linderman: Show quoted text
So here is code to a working work-around for the PAR problem of not extracting .dll files that refer to each other in a consistent place so that they can find each other. So for each module that needs to be unpacked, -X the module, and then create a -A list for it. For Image::Magick, that would have the following contents: manual_modules.txt: c:\perl\site\lib\auto\Image\Magick;lgl\auto\Image\Magick c:\perl\site\lib\Image\Magick.pm;lgl\Image\Magick.pm pp ... -X Image::Magick -A manual_modules.txt This could be done for several modules, if necessary. Corresponding code to put at the top of packaged script. sub PAR_fakeout { if ( $0 =~ m@[.]exe$@ ) # must be PAR, eh? { @INC = grep ref, @INC; # throw away everything but PAR unshift @INC, $ENV{'PAR_TEMP'} . '\\inc\\lgl'; } return; } sub PAR_extract { my ( $drive, $path, $zip ); $zip = PAR::par_handle( $0 ); $drive = substr( $ENV{'PAR_TEMP'}, 0, 2 ); $path = substr( $ENV{'PAR_TEMP'}, 2 ) . '\\inc\\lgl'; # return if -f $drive . $path . '\some.dll'; $path =~ s@\\@/@g; $zip->extractTree( 'lgl', $path, $drive ); return; } BEGIN { PAR_fakeout(); # do it at compile time PAR_extract(); # also extract .dll files from inside lgl path } PAR_fakeout(); # and also at run time PROs: It works. It might be a prototype for what a new PAR/pp option could do. CONs: It extracts the modules packaged this way on every run. Depending on their size, this may or may not be an issue. Clearly one _could_ code a -f check for a particular .dll file (since they are the ones PAR doesn't extract automatically) and assume that if one is there, they all are. Such a check would best be made on the last-to-be-extracted .dll file. This would hard code one file name in the above code, a commented form of the check is shown in the code. PAR extracts the non-DLL files, so those wind up getting extracted twice. One could play games enumerating all the various DLL files in one directory in the PAR file, and the non-DLL files in another, and then when doing the extract of DLLs extract the DLLs into the non-DLL directory... but that would exacerbate the next CON. And it is likely that the DLLs dominate the size of such modules anyway, so this CON is not nearly as severe as the previous one. It adds complexity to the build options. 'Twould be better if PAR/pp would take an extra option --always_extract_dlls_for Image::Magick that would cause them to be extracted along with the other source codes. Or even a switch with global applicability --always_extract_dlls that would apply to all DLLs, as everything works using this technique, unlike the current technique. Show quoted text
-- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

On approximately 10/6/2006 2:08 AM, came the following characters from the keyboard of Marc Lehmann: Show quoted text
Well, my understanding is that ImageMagick is kind of like your Gtk2... it pulls in the first .dll file, which goes looking for the rest of them, and they are nowhere to be found. The first one is unpacked as a temp file, so it cannot be found in the lib\auto\Image\Magick directory when looking at the par_cache area after the fact, either. But looking for a file of its size in the par_cache area, one can compare and discover that that first .dll does get extracted... but it can't find its siblings (which aren't referenced via standard Perl autoload techniques) by their proper names in the same directory as the first .dll. So I guess that is slightly different, but curing the "different name" and "different location" problems would seem to help us both. So I'm not at all sure what you have done to cure your problem. From what you said, I thought I was doing what you did up until the need to actually extract the .dlls to the right place. Show quoted text
If you are referring to the on-disk cache under $ENV{'PAR_TEMP'}, that is where I expected the Image::Magick .dlls to be extracted to. And some versions of PAR actually did it, and over time with "fixed" so that they didn't anymore. Show quoted text
Well, yes, it does, for files that it actually unpacks, which doesn't include the "other" ImageMagick .dll files as far as I can determine... there are a bunch of .dll files in the par cache, but not enough of the right byte size to be the ImageMagick ones. -- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking