[rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
Wed Jan 13 05:22:53 2021: Request 13508 was acted upon. Transaction: Correspondence added by RSCHUPP Queue: PAR Subject: cannot find Glib.dll on win32, despite being packaged in the exe Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: schm...@schmorp.de Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=13508 > Cleaning out old tickets...
[rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
Sun Nov 04 12:46:19 2012: Request 13508 was acted upon. Transaction: Correspondence added by RSCHUPP Queue: PAR Subject: cannot find Glib.dll on win32, despite being packaged in the exe Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: schm...@schmorp.de Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=13508 On 2012-10-31 21:33:13, mzhou wrote: We solved this problem for Biodiverse (http://biodiverse.googlecode.co) by patching PAR to extract DLLs with their original names instead of CRCs. I'm aware that names are much more likely to crash than CRCs, so perhaps an option embedded into the .exe when pp builds it could choose between whether to use name or CRC? The last thing PAR or PAR::Packer needs is another option! The correct solution is to stop extracting DLLs with CRC names altogether. Recent versions of PAR::Packer will extract any DLL with its full pathname anyway - except for the embedded ones (cf. PAR::Tutorial) which are extracted in stage 2 of the bootstrap of a packed executable. If this could be modified to use full pathnames, too, the whole CRC names thing could be removed. This would probably also remove the need for PAR to muck with DynaLoader. Cheers, Roderich
[rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
Wed Oct 31 21:33:13 2012: Request 13508 was acted upon. Transaction: Correspondence added by mzhou Queue: PAR Subject: cannot find Glib.dll on win32, despite being packaged in the exe Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: schm...@schmorp.de Status: open Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=13508 We solved this problem for Biodiverse (http://biodiverse.googlecode.co) by patching PAR to extract DLLs with their original names instead of CRCs. I'm aware that names are much more likely to crash than CRCs, so perhaps an option embedded into the .exe when pp builds it could choose between whether to use name or CRC? On Thu Feb 07 01:46:22 2008, azarah wrote: I have the same problem, and resolved it with the patch from bug #32589, and adding the DLLs via the -l switch (I do not package all the Gtk+ files, as I use a merge module with my installers). I also use Gtk2::GladeXML, which also needed to be added to the patch to work. Patch for reference and sample script I use to build the executables attached. Heavy.pm.patch Description: Binary data
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
On Fri, Sep 01, 2006 at 08:32:05AM -0400, Audrey Tang via RT [EMAIL PROTECTED] wrote: 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. I installed par-0.956 and modified my script (which worked fine with earlier versions of par), to: - no longer -X Gtk2 -X Glib - no longer include Glib.dll, Glib.pm etc. files for Glib and Gtk2 and promptly got the same problem again: Glib.dll not found. On closer inspection, Glib.dll is now indeed packaged, but still not found. Likely this is because it is not in the PATH, nor whereever Gtk2.dll expects it (namely in shlib/Glib.dll, while par packages it into lib/auto/Glib/Glib.dll). If not, please send me a one-liner that exhibits the problem (pp -e ...); I have no idea how to make a one-liner, because I still have to package all the libraries, and this makes it longer than the valid line length on windows. I would guess the moral equivalent that exhibits the problem is: pp -e use Gtk2 running under an environment not having perl but everything else (libgtk etc.). This would stop because Gtk2 can't find Glib.dll -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
On Thu, Oct 05, 2006 at 02:50:17AM -0400, Glenn Linderman via RT [EMAIL PROTECTED] wrote: 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 Now I understand. Your problem is similar, but ultimately different. My problem wasn't that dlls aren't being unpacked, but that they were being unpacked under the wrong name. use Glib; # pull in Glib.dll as _another_ name use Gtk2; # pull in Gtk2.dll and Glib.dll, which isn't anywhere So the dlls are being loaded and unpacked, but under the wrong name. Packaging Glib.dll manually did not work either, as Gtk2 would refer to Glib.dll and Glib would refer to the md5.dll copy, resulting in crashes. CONs: It extracts the modules packaged this way on every run. Depending on It should be made to use the cache par assumingly provides (I could never get the cache to work, so I do not use caching, but in theory that would alleviate the speed problems). -f check for a particular .dll file (since they are the ones PAR doesn't From what I read, par internally should do this, so when implementing such an option it could be taken care of. So the switch would trade a (possibly) slower first-time startup with a faster second-time startup. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: [rt.cpan.org #13508] 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 [EMAIL PROTECTED] wrote: If you need more info, I'd be happy to provide what I can. Hi Marc, packaging additional shared libraries into .par's or pp-ed binaries should be done with -l. You can't package a complete directory as far as I know. 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. P.S.: Sorry for the extremely belated reply. 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 ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
On Thu, Aug 31, 2006 at 03:46:37PM -0400, Steffen Müller via RT [EMAIL PROTECTED] wrote: URL: http://rt.cpan.org/Ticket/Display.html?id=13508 that par renames it to some gibberish file (as I already explained). FYI, that's because the dlls for various dependencies might clash. Well, they don't on the system where it is being packaged, so this is eitehr a bug or a limittaion in par that could be solved (e..g by not putting everything into a flat hierarchy and relying on the normla perl mechanism). -l is certainly not going to help as PAR does not load Glib.dll but Certainly... Have you tried? -l makes sure the name is retained because Yes, that was the first thing I tried. It still loaded the hash.dll instead of Glin.dll. 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). Right, I am the only one who managed to package gtk+ with perl on windows so far, to my knowledge, and I had to work around some other par bugs (such as adding its own defective entry to @INC _multiple_ times during program execution) but thats not the actual problem. The actual problem is and stays that par (version 1.52) does not correctly package perl modules using xs and shared objects. In case it matters, here is what I do a as workaround: 1. par keeps alot of crust in @INC leading to clashes if a user has a different but incompatible pelr installed: @INC = grep ref, @INC; # weed out all paths except pars loader refs 2. I pre-push my own libdir in @INC, both at BEGIN time as well as on main program start, because par pushes its own handler in front of it. 3. I manually package all Glib and gtk2-module related files into my own hierarchy. No @INC handler required, no renaming required, simply works. 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.) A bad habit, but no permanent harm was done. Your behaviour is frustrating to those who invest a lot of time investigating and openign bug reports. Many people I know don't have the stamina to reopen bug reports, especially if they aren't bold enough to know that they know the problem better than the ones caring for bug reports: It should be the opposite. On an unrelated note, if you are so inclined, retry using PAR 0.952 which might have a slightly different way of handling dlls. I will, although I can't say when, but as soon as I can. 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. If you don't care about fixing par then you are free to ignore bug reports. If you don't like the tone and this is the reason for not fixing bugs, then par stays as bad a product as it is. It might be that that is fine to you, and me, and everybody else, or might be a bad state of affairs. Its not my choice to make. Remember that its my spare time, too, and I invested far more time on this problem than you, giving a detailed bug report and being open to explain more if need be. I was not asking you to invest your spare time - you either give it, or if you don't want to give it, stay out of bug business. The only thing I ask is to not suppress valid bug reports (I am not saying that this is case here, of course!). If you don't honor this either and think its ok to frustrate people investing _their_ time to help, you might just as well ignore any bug reports. Thank you for investing your time. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
Hi list, Marc has added a CC to par@perl.org in this discussion which I missed. The answering function of RT doesn't preserve the CCs of the post you're answering. Hence my posts to the rt ticket queue don't show up on the list. For a full discussion please visit RT. Thanks. Steffen
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
[EMAIL PROTECTED] (Marc Lehmann) writes:
Right, I am the only one who managed to package gtk+ with perl on windows
so far, to my knowledge, and I had to work around some other par bugs
(such as adding its own defective entry to @INC _multiple_ times during
program execution) but thats not the actual problem.
I package Gtk2 with success using -l switch for Gtk2, Glib, GladeXML,
libglib, libglade, intl, libatk, libcairo, libgdk_pixbuf, libgdk-win32,
libgmodule, libgobject, libgthread, ligtk-win32, libpango,
libpangocairo, libpangowin32, libpng12, libpngf.
In the script during runtime I make directories relative to
$ENV{PAR_TEMP} where additional files necessary for gtk+ are being
copied.
PAR version is 0.951.
--
Radek
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
[EMAIL PROTECTED] (Marc Lehmann) writes: packaging additional shared libraries into .par's or pp-ed binaries should be done with -l. You can't package a complete directory as far as I know. I asked in this list about possibility to pack more libraries as it is with -A switch for files but there was no answer. So could it be added by a maintainer as a new feature? -- Radek
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite being packaged in the exe
rahed schrieb: [EMAIL PROTECTED] (Marc Lehmann) writes: packaging additional shared libraries into .par's or pp-ed binaries should be done with -l. You can't package a complete directory as far as I know. I asked in this list about possibility to pack more libraries as it is with -A switch for files but there was no answer. So could it be added by a maintainer as a new feature? Umm, you're quoting me there, not Marc. It could certainly be added. I suppose it's even reasonably simple. Since PAR supports Getopt::ArgvFile, it might not even be necessary though. I'll let you decide. If you would like that feature, go ahead and implement it! (Using code from -l and -A, this really shouldn't be hard, but I haven't looked.) Steffen
