--runlib Directory added to PATH

Hi,

Docs for both 6.0.2 and 6.9.92 say that --runlib is added to
the PATH?
It isn't in either case.

I'm trying out alternative approaches to Wx loading.

So, to get over the --runlib not on path issue, I can do in
a begin
block at the v.top of my script:

BEGIN {
$ENV = $PerlApp::RUNLIB . ';' . $ENV;
}

This still does not have the desired effect.
The script fails loading Wx.dll (due to not being able to
find
dependencies). This shouldn't happen as the dlls are on the
path.

So, before I delve into how precisely Wx is getting loaded,
it would be
good to know if PerlApp is doing a 'require Wx' or
equivalent before my
script gets run. If it is, it would be nice if
$PerlApp::RUNLIB were on
the path before that happened.

I know I can make it all work simply by binding the files.
What I find
odd is that if I bind just the three direct dependencies of
Wx, then it
all works with, for example, Wx::Html loading fine with
dependencies out
of the $PerlApp::RUNLIB. What seems odd is that Wx::Html
doesn't fail
too. I can't figure out, on the face of it, why Wx would
fail but not
Wx::Html.

I just want to test how start up times are affected by not
having to
extract the Wx Dlls.

Anyhow, the $PerlApp::RUNLIB not on path thing apart, all I
really need
to know is if PerlApp is doing something Wx specific that is
causing
this issue.

Thanks

Mark


_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

On Fri, 23 Feb 2007, Mark Dootson wrote:
> Docs for both 6.0.2 and 6.9.92 say that --runlib is
added to the PATH?
> It isn't in either case.

That looks like a bug; thanks for pointing it out.  I'm
surprised nobody
has noticed this before.

> I'm trying out alternative approaches to Wx loading.

Are you talking about Wx 0.26 as available binaries from the
sourceforge
site, or are you talking about a later version?  Is there
any good location
to download a pre-built wxPerl of later vintage?

> So, to get over the --runlib not on path issue, I can
do in a begin
> block at the v.top of my script:
>
> BEGIN { $ENV = $PerlApp::RUNLIB . ';' .
$ENV; }
>
> This still does not have the desired effect. The script
fails loading
> Wx.dll (due to not being able to find dependencies).
This shouldn't
> happen as the dlls are on the path.

This should have worked, if you put *all* the prerequisites
into the
runlib directory.  But I think Wx plays some weird games
with the loading
mechanism.  I would need more complete instructions to be
able to
replicate the problems myself.

> So, before I delve into how precisely Wx is getting
loaded, it would
> be good to know if PerlApp is doing a 'require Wx' or
equivalent
> before my script gets run. If it is, it would be nice
if
> $PerlApp::RUNLIB were on the path before that
happened.

No, it should not do any "use" or
"require" of its own.  The only thing
it does is to automatically bind all additional DLLs found
in the same
directory as Wx.dll and auto-extract them into the TEMP
directory,
which should be on the PATH.

[...]

> I just want to test how start up times are affected by
not having to
> extract the Wx Dlls.

Are you also using --dyndll? I would expect this to improve
startup time
too because the DLLs don't have to be written to disk at all
in this
case.

> Anyhow, the $PerlApp::RUNLIB not on path thing apart,
all I really
> need to know is if PerlApp is doing something Wx
specific that is
> causing this issue.

The bundling of additional DLLs mentioned above is almost
the only thing
(and it is not really Wx specific; there are a few other
modules that
also put additional libraries into the same directory as the
module itself).

The only other thing is that PerlApp recognizes Wx::wx_boot
as a hint
that the module uses DynaLoader/XSLoader and may need a
corresponding
DLL included too.

Cheers,
-Jan


_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

Thanks Jan,

I was looking at making sure Wx::Perl::Packager still worked
with 6.9.92
and what, if any, difference not having to extract the DLLs
would make -
plus how --dyndll affects the mix.

Had this not thrown up the --runlib issue, I would probably
not have
posted. There is a perfectly good working method of using Wx
- just use
Wx::Perl::Packager and manually bind the dlls if using Wx
> 0.50. The
only thing untested with this (by me at least) is the
--dyndll option.

I'll post again when I've figured why the problem I observed
occurs, if
only for interest.

I have set up MSWin PPM repositories for all things Wx - I'm
just
waiting for a reply from Mattia on whether he wants to host
these at
wxPerl site - so I won't post an URL yet.

Regards


Mark


Jan Dubois wrote:
> On Fri, 23 Feb 2007, Mark Dootson wrote:
>> Docs for both 6.0.2 and 6.9.92 say that --runlib is
added to the PATH?
>> It isn't in either case.
> 
> That looks like a bug; thanks for pointing it out.  I'm
surprised nobody
> has noticed this before.
> 
>> I'm trying out alternative approaches to Wx
loading.
> 
> Are you talking about Wx 0.26 as available binaries
from the sourceforge
> site, or are you talking about a later version?  Is
there any good location
> to download a pre-built wxPerl of later vintage?
> 
>> So, to get over the --runlib not on path issue, I
can do in a begin
>> block at the v.top of my script:
>>
>> BEGIN { $ENV = $PerlApp::RUNLIB . ';' .
$ENV; }
>>
>> This still does not have the desired effect. The
script fails loading
>> Wx.dll (due to not being able to find
dependencies). This shouldn't
>> happen as the dlls are on the path.
> 
> This should have worked, if you put *all* the
prerequisites into the
> runlib directory.  But I think Wx plays some weird
games with the loading
> mechanism.  I would need more complete instructions to
be able to
> replicate the problems myself.
> 
>> So, before I delve into how precisely Wx is getting
loaded, it would
>> be good to know if PerlApp is doing a 'require Wx'
or equivalent
>> before my script gets run. If it is, it would be
nice if
>> $PerlApp::RUNLIB were on the path before that
happened.
> 
> No, it should not do any "use" or
"require" of its own.  The only thing
> it does is to automatically bind all additional DLLs
found in the same
> directory as Wx.dll and auto-extract them into the TEMP
directory,
> which should be on the PATH.
> 
> [...]
> 
>> I just want to test how start up times are affected
by not having to
>> extract the Wx Dlls.
> 
> Are you also using --dyndll? I would expect this to
improve startup time
> too because the DLLs don't have to be written to disk
at all in this
> case.
> 
>> Anyhow, the $PerlApp::RUNLIB not on path thing
apart, all I really
>> need to know is if PerlApp is doing something Wx
specific that is
>> causing this issue.
> 
> The bundling of additional DLLs mentioned above is
almost the only thing
> (and it is not really Wx specific; there are a few
other modules that
> also put additional libraries into the same directory
as the module itself).
> 
> The only other thing is that PerlApp recognizes
Wx::wx_boot as a hint
> that the module uses DynaLoader/XSLoader and may need a
corresponding
> DLL included too.
> 
> Cheers,
> -Jan
> 
> 


_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

The fault is mine.

My normal instruction is that Wx::Perl::Packager should go
first in a
BEGIN block at the start of your script.

So, to have the Wx dlls in a different none packaged
location, I put:

BEGIN {
 $ENV = $PerlApp::RUNLIB . ';' . $ENV;
 use Wx::Perl::Packager;
}

Don't laugh. Of course, the first thing that gets executed
in the above
is 'use Wx::Perl::Packager;' . sigh.

BEGIN { $ENV = $PerlApp::RUNLIB . ';' . $ENV; 
}
use Wx::Perl::Packager;

works perfectly well with PerlApp happy to find the Wx dlls
on the path.

So I just need to find a way to have Wx::Perl::Packager in a
BEGIN block
accept an optional runtime determined path that it will
pre-pend to
$ENV. ( I might not always want to use --runlib as the
location ).

I imagine something in import will be the answer:

e.g.

BEGIN { use Wx::Perl::Packager ( wxpath => 'something
here' ); }

Of course, I could just bind the dlls and have done with
it.

A separate point - using --dyndll, switching this option on
causes a
segfault on exit. (It will be caused by loading / unloading
or not of
the html wx dll)

I'll have a look again at what wx_load and wx_unload do as
amended by
Wx::Perl::Packager.

I'd have to say that the discernable difference as a user of
starting my
test app with and without the wx dlls bound in seems
subjectively pretty
small to me so I'm losing the incentive to chase this right
to the end.
 - I will, however test out the --dyndll segfault properly
and post
details.


Regards


Mark






Mark Dootson wrote:

>>> Anyhow, the $PerlApp::RUNLIB not on path thing
apart, all I really
>>> need to know is if PerlApp is doing something
Wx specific that is
>>> causing this issue.



_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

> I'd have to say that the discernable difference as a
user of starting my
> test app with and without the wx dlls bound in seems
subjectively pretty
> small to me so I'm losing the incentive to chase this
right to the end.
> - I will, however test out the --dyndll segfault
properly and post
> details.

Mark,

Fascinating discussion, though as I've never used Wx nor
even know what it 
is at this point I can't attest to having any
insights...)

Anyway, you've seemed to solve the problem mostly. I just
wanted to comment 
on the point you make above...:

There may be a reason to ensure it works with our without
--dyndll, 
regardless of perceived speed gain in your test app. Why?
Because 
since --dyndll is an all or nothing proposition, speed may
become an issue 
for those that uses both Wx *and* a number of other modules
needing dll's, 
perhaps some of which have many and/or very large dll's - in
which case 
there's a significant speed gain by using --dyndll.

Well, at least this is how I understand it...perhaps this
should end up as 
yet another configurability item in perlapp  - enabling
us to say 
something to the effect of ' I want to use the --dyndll
mechanism for dll A, 
B and C, but not D because it is incompatible with it', or
so...

ken1 

_______________________________________________
PDK mailing list
PDKlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs