Program aborts looking for perl58.dll when 5.12.1 is installed

Posted by hbullock on 2010-09-21 06:18

I have ActivePerl 5.12.1 installed. When I attempt to use PerlApp 9.0 to compile the script, the resulting program fails to start complaining it can not find perl58.dll

Running "perl -V" in a command window also produces the same result. This would indicate that something is corrupted in the my perl installation.

Can anyone provide me with a quick fiux or insight into the issue. Other wise I will need to uninstall/reinstall and relaod all my modules.

hbullock | Tue, 2010-09-21 06:53

I have unstalled 5.12.1 ansd installed 5.12.2. When I execute perl -V in a CMD window, I again receive an error that perl is looking for perl58.dll.

grahams
ActiveState Staff
Tue, 2010-09-21 15:42

Modules can't be directly transferred across a Perl major revision boundary. Modules built for Perl 5.8 will be incompatible with Perl 5.12.

http://docs.activestate.com/activeperl/5.12/install.html#upgrade

hbullock | Tue, 2010-09-21 15:55

Modules are not deleted when you uninstall ActivePerl? The text you link to states, "Upgrading from earlier ActivePerl versions requires that you delete the old version of ActivePerl, and then install the 5.10.x version. This means that any additional packages that were installed using PPM must be manually reinstalled after the ActivePerl 5.10.x installation, so creating a list of these packages is an important first step."

This seems to indicate that, as I expected, the manually installed modules are deleted when ActivePerl is uninstalled. This clearly states one has to back the module list prior to uninstalling which means they should be automatically deleted.

grahams
ActiveState Staff
Tue, 2010-10-19 13:15

Microsoft uninstaller runs off a list of files which were present in the original installer. If you add files into the directory after the installer runs, uninstall will not be able to remove them. Furthermore, if there are files in a directory, the uninstaller will not delete it, even if the installer originally created the directory. This is standard behavior.

Any module with a binary component will not work if you attempt to run it with a newer major version of Perl. The uninstaller won't remove it, and if you don't manually remove it (as described in that link) your newer Perl will be borken when it finds and runs that module. Generally, it will complain about the wrong version of the Perl dll.