Re: ActiveState's PerlApp is causing an odd problem with IO:Socket

in reply to ActiveState's PerlApp is causing an odd problem with IO:Socket

In my PerlApp 4.1.2 the info below is found in the docs.

--add <list>
List additional modules to include in the executable.
PerlApp will also try to include modules that the listed modules depend on. Multiple modules can be separated by whitespace or a semi-colon. The option can be repeated.

For example:
perlapp myscript.pl --add IO::Socket;XML::Parser::Expat
would cause IO::Socket and XML::Parser to be included in your executable.

Your PerlApp version seems older, so the syntax may have changed
HTH

Comment on Re: ActiveState's PerlApp is causing an odd problem with IO:Socket

Replies are listed 'Best First'.
The -add does nothing different... by lclemmer (Initiate) on Dec 04, 2002 at 23:13 UTC
Thanks for the reply, Yes, the syntax is the same. I'm puzzled too as I thought I had a newer version of PerlApp (and the Dev kit) However, that bit doesn't help. PerlApp already saw the use of the module and included it, and manually/explicitly putting it in there doesn't help. Same error. Any other ideas, anyone?	[reply]
Here's the offending line of code, HTH by lclemmer (Initiate) on Dec 04, 2002 at 23:28 UTC
From Socket.pm: `my $sel = new IO::Select $sock;` This code works fine when I use socket functions in runtime perl, and it works fine with PerlApp compiled code that is "dependent" on Perl being on the system. It's the freestanding version only that doesn't work. The modules are getting added to the .exe when it's compiled, and they're explicitly use'd in the program. I'm going to go dig up a newer version of PerlApp if I have it here and see what happens. Lee	[reply] [d/l]
Re: Here's the offending line of code, HTH by jand (Friar) on Jan 21, 2003 at 01:44 UTC
I think you may need to use a later version of ActivePerl as well (at least build 628 or later). I believe your problem is related to the overriding of CORE::GLOBAL::require by PerlApp. The require statement has both runtime and compiletime aspects, and in earlier versions the compiletime aspects are suppressed when require has been overriden. The problem is that the statement `my $sel = new IO::Select $sock;` [download] uses indirect object syntax. Directly above is the require statement: `require IO::Select;` [download] With a non-overridden require, it will create the IO::Select package at compile time and the statement above is compiled as `my $sel = IO::Select->new($sock);` [download] Without the compiletime definition of the IO::Select package, Perl compiles it as `my $sel = new($sock->IO::Select());` [download] because the IO::Socket module had already defined a new() sub at this time. Another "fix" would be to add a `use IO::Select;` [download] line to the top of your script.	[reply] [d/l] [select]
Re: Here's the offending line of code, HTH by chinman (Monk) on Dec 05, 2002 at 03:55 UTC
You might want to post to the Active State PDK e-mail list . The list is moderated by Jan Dubois who is very responsive at answering questions. It looks like the problem you describe was observed previously in PDK 3.0. They just released PDK 5.0 today, you may be in luck! Regards, chinman	[reply]
Good call, that's it exactly. (I'll bet) by lclemmer (Initiate) on Dec 05, 2002 at 20:30 UTC
RESOLVED by lclemmer (Initiate) on Dec 06, 2002 at 19:02 UTC
Updating to the latest Perl Dev Kit from ActiveState resolves the problem with "finding" included library functions. It works properly now. Of course I found a major problem with my code... so, off to the races...	[reply]

In Section Seekers of Perl Wisdom