I spent a very long time trying to get PAR::Packer to work under ActivePerl and finally gave up.
That's odd, I have activeperl (v5.10.0) and whatever PAR::Packer version PPM gave me and I never had a problem so far (Windows XP 32 bit). | [reply] |
Finally, when I use ActivePerl v5.10.0, the Par::Packer works. But it does not work on ActivePerl v5.10.1 and v5.12.2, two versions which ActiveState provides downloads on their websites.
So I think I have to downgrade to ActivePerl v5.10.0.
Thank you for sharing.
Xingliang
| [reply] |
Well, I suppose everyone's experiences will differ. The last ActivePerl version I have is 5.10.1 and I'm using XP.
I recall spending some months following the bug reports quite closely and trying whatever patches became available on CPAN.
If it helps anyone, I'm currently using Strawberry Perl 5.12.0 and PAR::Packer 1.006
| [reply] |
Maybe you should have installed a compiler? | [reply] |
| [reply] |
Why do you think you get the
It looks like you don't have a C compiler on your PATH, so you will no
+t be
able to compile C or XS extension modules. You can install GCC from t
+he
MinGW package using the Perl Package Manager by running:
message?
| [reply]
[d/l] |
I tried several times to switch to Strawberry Perl. But installing modules such as DBD::Mysql became a daunting task for me and I never succeeded. It always failed this test or that test and even "force install" does not help. How do you resolve module installation problem using Strawberry? I was using CPAN module that comes together with Strawberry. But since you are using strawberry happily, there must be some tricks I donot know.
Would you like to share some tips?
Thank you,
Xingliang | [reply] |
Actually, I said "... using pp quite happily ...". However, I am generally pleased with Strawberry Perl.
I've found most modules install using the CPAN modules but occasionally some don't. And, yes, force install doesn't always help. There is actually a stronger version of that (fforce) but there are cases where that's not the answer either.
When the CPAN module hasn't been able to install a module, I revert to the commandline. The usual incantation is
perl Makefile.PL
make
make test
make install
but do check the README and INSTALL files for variations, dependencies or additional tasks that may need to be run.
One point of failure is often make test. There are occasions where the module has built without any problem and will install and run OK but, for whatever reason, one or more tests fail. While I'm not advocating that you skip the tests as a general rule, you can try the make install even if make test failed. I would recommend looking at the test output: the reason for failure may be obvious, e.g. you don't have some server running, your internet access is currently down, and so on.
With regard to DBD::Mysql, I can't provide any advice from (recent) personal experience - I may have installed that module 10 years ago. What I do recall from installing DBD::* modules generally is that you need to read the README and INSTALL documents very closely.
| [reply]
[d/l]
[select] |
ppm install ...
Maybe it is not time to switch yet.
| [reply]
[d/l] |