If that's how it's done, I think this happens: Your program has been built as a perl interpreter which has the compiled bytecode of your perl program included.
Note that this will include all the supplied Perl modules, too. Unfortunately Perl2Exe is actually a perl5.6.0, while you have an ActiveState perl5.6.1.

Thus your library pathes are different...
I'd try if that error still occurs when removing the ActiveState perl or running perl2exe on your program on a computer which has never seen any perl installation

If any of this fails, I suggest you try to get a hold of an old ActiveState perl5.6.0
an try again.

Who is the vendor of perl2exe? (I remotely remember fooling around with that...but it's not coming to me right now...:-)).
The vendor should have a perl5.6.1 version of perl2exe IMHO.
Otherwise I would count it as a discontinued product and refrain from using it.

IMHO everyone's served better if you bundle a perl installation with all required modules/libraries/custom programs and just installed that at your clients' location.

Kay

I don't use Perl2exe, but it might be that your version of it (has an error|is outdated).

Might I also suggest against using Perl2exe unless you really have to. Even something like installing Perl on 58 Windows machines so your client-server script can run calls for the installation of something like ActiveState Perl on the aforementioned machines. The perl-to-exec compilers aren't that great/reliable, and it's best to keep your code as-is so that it can change with the times.

Considering the inclusion of the Tk modules, your program (after compiling) will be somewhat large.

If you are using Perl2exe to "protect" your source, Perl2exe offers a false sense of security. If your code is under a strict license, I advise shipping it encrypted and having a subroutine that reports back to you with registered information, just to keep things legal.

Opinions may differ, but I see no practical application where Perl2exe is necessary.

Perl2exe can also cause its on headaches, like the one you encountered, and the little registration hassle it imposes on Unix machines.

Try redownloading Perl2exe, after finding the most current version. If you wouldn't mind, could you elaborate on what you are using it for? Perlhaps there's a better method.

Hope this helps.

John J Reiser
newrisedesigns.com

I'd be glad to elaborate (and I'd be glad to keep it a .pl file, unfortunately I'll only be able to do the former).

This summer I'm working at NASA Langley developing some applications. I need the perl2exe (or its ActiveSTate counterpart, which is causing its own headaches as we speak) because the programs I'v written are to be run on another computer to get data from pilots after they run certain conditions in a flight simulator. A GUI was desired, and when I told my employer that Perl and TK would need to be installed on the computer it would be run on (and that perl was an interpreter), he asked if I could make it an exe.

I'm pretty sure I downloaded the latest version, but I'll try again (but right now, after downloading, unistalling, and redownloading, WIndows INstaller is spewing out error messges that won't let me install at all!).

Update:

Well, PerlDevKit pulls through! Thanks for the suggestions...

As someone who has to install a lot of software on 100+ pcs I know where you are coming from. But one thing i notice from the java world is that nearly all java apps ship with a /jre folder containing the exact Java version that the project was built on, as well as a .bat file to set environmental variables and start the app. I imagine if I ever get around to doing a full network install of one of my perl programs I might do something similar(I'm the only developer here who codes in Perl).Make a folder with a copy of the necessary perl executables modules and dll's to make the app work and deploy it

I imagine the batch file for such an app in perl would look like this.

set PATH=%PATH%;.\Perl\bin
perl application.pl
[download]