Re: Undefined subroutine Scalar::Util::refaddr
On Thu, 2006-11-09 at 01:14 +0100, Roderich Schupp wrote: On 11/7/06, Peter Gordon [EMAIL PROTECTED] wrote: At this point either I have made a mistake and/or am thoroughly confused. No, it's what I suspected. Your build of PAR has been done against some older version of perl (or at least of Scalar::Util) - that's the stuff extracted with my script. It's probably a bug that a second, newer version was also culled from the pp'ing system - that's the stuff extracted with unzip. But anyway, the old stuff is used once the pp'ed executable gets invoked and it doesn't fit well with newer stuff from the pp'ing system. This problem is currently heavily discussed in another thread on the par mailing list. The only thing missing in the puzzle is: why is this older stuff present? It's burned into PAR at PAR build time, but you said you built PAR yourself on the pp'ing machine, and didn't reinstall perl or Scalar::Util in the meantime. Maybe there is a misunderstanding here. I am using the ActiveState version of Perl, so I didn't build it myself. A local fix for me has been to eval the offending line. Perhaps there are remnants of an old perl installation on that machine that you aren't aware of? (e.g. another recent poster with a similar problem discovered an older perl58.dll in his c:\windows\system32 directory, apparently installed by a third party application and picked up because of some peculiar rules on Windows how to locate DLLs). As for the flashing-windows-when-using-backticks thing: I once wrote an application using Tk, it drove a third party app using their command line interface (including reading and interpreting the output of such). It used IPC::Run3 for that. When I pp'ed it with --gui it didn't have the flashing windows effect. In any case, IPC::Run3 uses system() internally (it does some fancy redirecting beforehand and afterwards to handle the capture/feeding of stdin/stdout/stderr, though), so I'm surprised that you see different behavious for system() and IPC::Run3. I'll try to experiment a little over the weekend. Thanks, Peter Cheers, Roderich
Re: Undefined subroutine Scalar::Util::refaddr
Hi Roderich, hi Peter, Roderich Schupp schrieb: [...] As for the flashing-windows-when-using-backticks thing: I once wrote an application using Tk, it drove a third party app using their command line interface (including reading and interpreting the output of such). It used IPC::Run3 for that. When I pp'ed it with --gui it didn't have the flashing windows effect. In any case, IPC::Run3 uses system() internally (it does some fancy redirecting beforehand and afterwards to handle the capture/feeding of stdin/stdout/stderr, though), so I'm surprised that you see different behavious for system() and IPC::Run3. I'll try to experiment a little over the weekend. When - or rather if - one of you figures this out, would you consider adding an entry to the FAQ list in the PAR wiki at par.perl.org? I am pretty certain that you're not the first to suffer from this effect. Thanks! Steffen
Re: Undefined subroutine Scalar::Util::refaddr
On 11/7/06, Peter Gordon [EMAIL PROTECTED] wrote: At this point either I have made a mistake and/or am thoroughly confused. No, it's what I suspected. Your build of PAR has been done against some older version of perl (or at least of Scalar::Util) - that's the stuff extracted with my script. It's probably a bug that a second, newer version was also culled from the pp'ing system - that's the stuff extracted with unzip. But anyway, the old stuff is used once the pp'ed executable gets invoked and it doesn't fit well with newer stuff from the pp'ing system. This problem is currently heavily discussed in another thread on the par mailing list. The only thing missing in the puzzle is: why is this older stuff present? It's burned into PAR at PAR build time, but you said you built PAR yourself on the pp'ing machine, and didn't reinstall perl or Scalar::Util in the meantime. Perhaps there are remnants of an old perl installation on that machine that you aren't aware of? (e.g. another recent poster with a similar problem discovered an older perl58.dll in his c:\windows\system32 directory, apparently installed by a third party application and picked up because of some peculiar rules on Windows how to locate DLLs). As for the flashing-windows-when-using-backticks thing: I once wrote an application using Tk, it drove a third party app using their command line interface (including reading and interpreting the output of such). It used IPC::Run3 for that. When I pp'ed it with --gui it didn't have the flashing windows effect. In any case, IPC::Run3 uses system() internally (it does some fancy redirecting beforehand and afterwards to handle the capture/feeding of stdin/stdout/stderr, though), so I'm surprised that you see different behavious for system() and IPC::Run3. I'll try to experiment a little over the weekend. Cheers, Roderich
Re: Undefined subroutine Scalar::Util::refaddr
On Mon, 2006-11-06 at 14:38 +0100, Steffen Mueller wrote: Roderich Schupp schrieb: [...] You could try what happens for system() (don't remember). If system() doesn't flash a DOS box with --gui, you could replace the backticks by using IPC::Run3 (that allows you to catch stdout/stderr into a string, but way more flexible as backticks), because it uses system() internally. If system() doesn't work, maybe some advanced use of Win32::Process and/or Win32::Console might to the trick? Make sure you use the multi-argument form of system() because that should avoid the console! IPC::Run3 flashes - so that didn't help. system() might be ok, but without a shell I can't redirect output - or at least I don't know how to. Peter
Re: Undefined subroutine Scalar::Util::refaddr
On 11/6/06, Peter Gordon [EMAIL PROTECTED] wrote:
has Scalar/Util.pm (and also Scalar/Util.so or Scalar/Util.dll) been
packaged,
run unzip -l your_executable to check
# unzip -l app_diag.exe | grep Util
56: 2050 11-06-06 08:21 lib/List/Util.pm
61: 3572 11-06-06 08:21 lib/Scalar/Util.pm
117:0 11-06-06 08:21 lib/auto/List/Util/Util.bs
118:32871 08-29-06 12:49 lib/auto/List/Util/Util.dll
119: 789 08-29-06 12:49 lib/auto/List/Util/Util.exp
OK, they are in the zip part (but stale copies might also be in the
embedded stuff
of the executable). Could you run the attached script on app_diag.exe and
check whether the extracted Util.* stuff matches your installed stuff
(pm's might have comments/pod stripped, that's normal).
- did you build PAR yourself (esp. on Windows) on the computer where you
did the pp'ing?
Yes
... and with the version of perl and Scalar::Util that is now installed?
There is an odd thing that I noticed in Archive::Tar.pm, which may
provide a clue to what is happening.
BEGIN {
use Config;
$HAS_PERLIO = $Config::Config{useperlio};
### try and load IO::String anyway, so you can dynamically
### switch between perlio and IO::String
eval {
require IO::String;
import IO::String;
};
$HAS_IO_STRING = $@ ? 0 : 1;
Shouldn't be a problem.
1. Besides adding lots of print statements, is it possible to debug a pp
package?
Sorry, no, because you can't pass the -d switch down to the packaged
version of perl.
If I unpack the files, is it then possible to use -d somehow?
Again no, because it is using a custom-built perl interpreter that does not
obey the -d switch (and has no other way to enable debug mode):
I also have another problem: I run external programs using backticks and
pack without using the --gui flag. When the user double clicks on the
file name a dos box shows. With the --gui flag, no dos box shows, but on
the other hand, every time I run the backticks, a dos box starts up and
closes down, which appears as a flashing dos box to the user. This does
not happen without pp.
I know that one, but see no easy fix.
What happens is this:
- programs started with backticks need to run in
a DOS box, otherwise Windows won't endow them with stdin/stdut/stderr
- the perl runtime knows about this and will start the program in a DOS box
if itself isn't runing in one already
- so without --gui, you already got one, no need to create any for backticks
(but of course the users sees the initial DOS box)
You could try what happens for system() (don't remember). If system() doesn't
flash a DOS box with --gui, you could replace the backticks by using
IPC::Run3 (that allows you to catch stdout/stderr into a string, but way more
flexible as backticks), because it uses system() internally.
If system() doesn't work, maybe some advanced use of Win32::Process and/or
Win32::Console might to the trick?
Cheers, Roderich
extract-embedded.pl
Description: Perl program
Re: Undefined subroutine Scalar::Util::refaddr
Roderich Schupp schrieb: [...] You could try what happens for system() (don't remember). If system() doesn't flash a DOS box with --gui, you could replace the backticks by using IPC::Run3 (that allows you to catch stdout/stderr into a string, but way more flexible as backticks), because it uses system() internally. If system() doesn't work, maybe some advanced use of Win32::Process and/or Win32::Console might to the trick? Make sure you use the multi-argument form of system() because that should avoid the console! Steffen
Re: Undefined subroutine Scalar::Util::refaddr
On 11/5/06, Steffen Mueller [EMAIL PROTECTED] wrote: My money is on option three. Blech, mine too. The thought occurred to me that we might solve this problem by appending the required modules to a stripped-down copy of parl.exe just before I just did a little experiment (on Linux, but should work on Windows, too) and stripped my /usr/bin/parl and /usr/bin/parldyn. This gets rid of all the embedded FILE stuff in there (because it is simply appended to the executable, i.e non-existent w.r.t to strip). I then pp'ed a hello world example... and it works :) I verified that running the executable doesn't load anything from outside /tmp/par-USER. Also, my extract the embedded stuff script shows that the embedded stuff (e.g. Scalar/Util.pm) is still packed in and that is from the running system (because I added a tell-tale line to Scalar/Util.pm beforehand) and NOT from the time when PAR was build. Now the only stuff left in parl is the perl58 DLL (because it is not embedded, but compiled in). So for the prototypical-packed-executable aspect of parl, we can just leave out the embedded stuff. But parl may also work as a standalone loader (no perl or modlues required) for PAR archives, that wouldn't work with the stripped version anymore. Hence we should split parl into two entities. Cheers, Roderich
Re: Undefined subroutine Scalar::Util::refaddr
Roderich Schupp schrieb: On 11/5/06, Steffen Mueller [EMAIL PROTECTED] wrote: The thought occurred to me that we might solve this problem by appending the required modules to a stripped-down copy of parl.exe just before I just did a little experiment (on Linux, but should work on Windows, too) and stripped my /usr/bin/parl and /usr/bin/parldyn. This gets rid of all the embedded FILE stuff in there (because it is simply appended to the executable, i.e non-existent w.r.t to strip). I then pp'ed a hello world example... and it works :) I verified that running the executable doesn't load anything from outside /tmp/par-USER. Also, my extract the embedded stuff script shows that the embedded stuff (e.g. Scalar/Util.pm) is still packed in and that is from the running system (because I added a tell-tale line to Scalar/Util.pm beforehand) and NOT from the time when PAR was build. Now the only stuff left in parl is the perl58 DLL (because it is not embedded, but compiled in). So for the prototypical-packed-executable aspect of parl, we can just leave out the embedded stuff. But parl may also work as a standalone loader (no perl or modlues required) for PAR archives, that wouldn't work with the stripped version anymore. Hence we should split parl into two entities. I experimented a little, too. What I did first was to just copy static over parl. I also tried to strip parl. Neither of them picked up the system's Scalar::Utils during packaging. What did you do to make it work? Steffen
