-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey All,

Just as a followup, I got the following response to my problem on the
wxPerl mailing list. Would seem to be a case of perlapp not being able
to execute the code to find dependancies.

Regards
Darryl


- -------- Original Message --------
Subject: Re: [wxperl-users] Can't build wxperl 0.23 applications under
PerlApp 5.3.0
Date: Wed, 06 Jul 2005 07:15:16 -0700
From: Peter Riley <Peter.Riley@xxxxxxxxxxxxxx> 
Reply-To: Peter.Riley@xxxxxxxxxxxxxx
To: Darryl Ross <spam@[...].com> 
CC: wxperl-users@[...].net
References: <42C88CB4.1090607@[...].com> 


Hi.  The culprit is on line 5 of your test script:

use Wx 0.15 qw[:allclasses];

PerlApp chokes on the ":allclasses" parameter.  You can
probably just get rid of it like this

use Wx 0.15;

or explicitly name whatever classes you really need to use.


> 
>  Not sure if this is a problem with the wxPerl module or PerlApp, so I'm
>  going to send this message to both lists.
> 

Perhaps you might forward the following info to the other
list if you think it could help...

The real problem here is that, when it scans for dependencies
to package up, PerlApp can't deal with the "eval _get_packages()"
in the Wx::import sub of the Wx.pm module on line 63:

Wx.pm (wxPerl 0.23)
- -------------------
56: # handle :allclasses specially
57: sub import {
58:   my $package = shift;
59:   my $count = 0;
60:   foreach ( @_ ) {
61:     m/^:/ or last;
62:     m/^:allclasses$/ and do {
63:       eval _get_packages();    ### <--- PerlApp crash!
64:
65:       die $@ if $@;
66:
67:       splice @_, $count, 1;
68:     };
69:
60:     ++$count;
61:   }
62:
63:   $package-> export_to_level( 1, $package, @_ );
64: }

The _get_packages() sub is an XS function (which is loaded
from Wx.dll) that simply returns a static const string
containing the classes available in the particular wxPerl
build.

I found it is defined in Constant.xs in the wxPerl source,
and it uses the preprocessor to build up the static return
string based on the build parameters defined at the build
time of wxPerl itself:

Constant.xs (wxPerl 0.23)
- -------------------------
2225: char*
2226: _get_packages()
2227:   CODE:
2228:     static const char packages[] = ""
2229: #if wxPERL_USE_DND && !defined(__WXMAC__) && !defined(__WXMOTIF__)
2230:     "use Wx::DND;"
2231: #endif
2232: #if wxPERL_USE_DOCVIEW && !defined(__WXMAC__)
2233:     "use Wx::DocView;"
2234: #endif
2235: #if wxPERL_USE_FILESYS
2236:     "use Wx::FS;"
2237: #endif
2238: #if wxPERL_USE_GRID
2239:     "use Wx::Grid;"
2240: #endif
2241: #if wxPERL_USE_HELP
2242:     "use Wx::Help;"
2243: #endif
2244: #if wxPERL_USE_HTML
2245:     "use Wx::Html;"
2246: #endif
2247: #if wxPERL_USE_MDI
2248:     "use Wx::MDI;"
2249: #endif
2250: #if wxPERL_USE_PRINTING_ARCHITECTURE
2251:     "use Wx::Print;"
2252: #endif
2253: #if wxPERL_USE_SOCKET
2254:     "use Wx::Socket;"
2255: #endif
2256: #if wxPERL_USE_CALENDAR
2257:     "use Wx::Calendar;"
2258: #endif
2259: #if wxPERL_USE_DATETIME
2260:     "use Wx::DateTime;"
2261: #endif
2262:     ;
2263:
2264:     RETVAL = (char*)packages;
2265:   OUTPUT:
2266:     RETVAL

For example, when I call it on WinXP, I get the following
return value from the function as output:

E:\Temp> perl -e "use Wx; print Wx::_get_packages();"
use Wx::DND;use Wx::DocView;use Wx::FS;use Wx::Grid;use
Wx::Help;use Wx::Html;use Wx::MDI;use Wx::Print;use
Wx::Socket;use Wx::Calendar;use Wx::DateTime;


Anyway, it's clear that "eval _get_packages();" is a fairly
straightforward *runtime* operation. I don't know if PerlApp
has any fancy techniques to handle even simple situations
like this in its dependency checking, before run-time.

If PerlApp merely does Perl-code-only source-level scanning,
it can never see static const strings containing the names
of class dependencies in autoloaded DLL functions. If it is
trying to do something more sophisticated with the eval,
maybe that's where the memory access crash is occurring...?


Best Regards,
- -PWR



Darryl Ross wrote:
>  Heyas,
>  
>  Not sure if this is a problem with the wxPerl module or PerlApp, so I'm
>  going to send this message to both lists.
>  
>  When I try to build the attached wxPerl program I get the following error:
>  
>  """
>  The instruction at "0x01217093" referenced memory at "0x01a73038". The
>  memory could not be "read".
>  
>  Click on OK to terminate the program.
>  """
>  
>  This happens with my main application that I've been writing for over a
>  year, but it also happens with the "simple" case program which was
>  created using wxglade and with only a static text on the frame.
>  
>  One thing I find really strange is that both of the memory locations
>  given remain the same even across a reboot and compiling different programs.
>  
>  The output I get from PerlApp is:
>  
>  """
>  C:\Temp>perlapp helloworld.pl
>  PerlApp 5.3.0 build 530
>  Copyright (C) 1998-2003 ActiveState Corp.  All rights reserved.
>  ActiveState is a division of Sophos Plc.
>  Commercial license for Mike O'Connor <mike@[...].au>
>  
>  -e syntax OK
>  'helloworld.pl' had compilation errors.
>  """
>  
>  Platform is WinXP-SP2.
>  
>  Any ideas?
>  
>  Regards
>  Darryl
>  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCzF35/XQ6DbmPjokRAqIpAJ97FBPWnwPA/KOBOSFuzk6z95CyzQCdE3gu
2/EyIoTjtHchdo++YWVYNgM=
=078r
-----END PGP SIGNATURE-----
_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs