Jason Zwolak wrote:
> because 0.89 does not work correctly on Windows with ActiveState Perl
> 5.8.7.
>
PAR 0.89 works just fine on Windows XP Pro with ActiveState Perl 5.8.7.
I know that does not mean it works fine for you on your machine.
As far as the PL_memory_wrap problem is concerned, there have been
others who got that problem. It was worked on this past June and July
by others. AFAIK it was fixed. Reviewing the June/July emails may
reveal clues.
There were also problems (something about procedure entry point,
sometimes associated with the "PL_memory_wrap" verbiage) that arose.
Sometimes it was because there was no
PAR-0.89-MSWin32-x86-multi-thread-5.8.7.par, which automatically gets
fetched during the "Perl Makefile.PL" step of installation. I think one
or more persons were trying to work around it by using the PAR made for
5.8.6, which does not work. Or else compiling it themselves with one
compiler version, and compiling perl with another, which did not work.
Something like that. I don't fully remember about the PL_memory_wrap
issues here.
I would reccomend retrying Perl 5.8.7 and PAR 0.89. In truth I am not
savvy enough to understand the PL_memory_wrap problems that were worked
on (by others, obviously) but again, Perl 5.8.7 and PAR 0.89 work just
fine. I have experimented with a *lot* of modules, and none gave me
problems.
Having written the above, I have to say I have never tried Inline-Java-0.50.
I see you are mixing (packing) cygwin binaries
-a c:/cygwin/home/jzwolak/files/biopack/bin;biopack/bin"
with normal (normal to me, that is) windows perl modules. I have never
seen that before, either. I just tried "c:\cygwin\bin\ls" from within a
regular windows prompt box and it worked. Will all of the cygwin
binaries work outside of the cygwin shell? Could there be a problem in
that area? Is there a way to test for it? Just a thought. I assume
everything works prior to creating the executable with pp, so you
probably can just ignore this paragraph.
I notice you do not have the full path name of "biopack/bin". I don't
know what your setup is but if in doubt, I would use the fully qualified
path name when packing that, too.
If default_j2sdk.pl is suspect, with it's usage of '\', it might be
worth making them all "\\" and retrying. If everything works fine prior
to the pp stage, this probably is not an issue. Still, since it is easy
to do, it may be worth trying.
The only other thing I can think of is to do a gross debug to get to the
most errent portion of the problem. For example comment out half of
your calls (and concomitant "use no-longer-needed-module" modules) and
see if the problem goes a way, then another half, if the problem is
still there, etc., to get the most stripped down amount of code that
will still exhibit the problem. Debug is never really quite this easy,
but you get the general idea. If code can be stripped out with the
problem still existing, strip it out.
Good luck.
