Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I have a perl cgi script, that I is used very frequently by my colleagues etc. and it's present in my machine (Windows 2000 Professional). Due to relocation, I had to implement the script in machines which don't have perl installed and so I converted it to an exe. The home page now calls the exe and script works fine. (converted using a perl2exe pro registered version).

My question is whether the same exe would work on a Unix Machine (Solaris 5.6). If not, do I have to modify the way the script that was written with Active perl for Windows in mind? (Other than CGI module, I've used benchmark which I think I should be able to install it into the Unix Box).

Replies are listed 'Best First'.
Re: perl2exe question
by Roger (Parson) on Sep 23, 2003 at 07:03 UTC
    No! The DOS exe binary is not going to work on a Unix machine. What perl2exe is doing -> it compiles perl into opcodes, and then attaches the compiled opcode after a stub which is a PC binary file. If you run this program, the perl stub will seek to its end to locate the Perl opcode, and then execute the opcode with its built-in interpreter.

    Sun runing Solaris 5.6 is a totally different architecture to PC, it is not binary compatible with PC at all. You can not expect the same EXE to work under Solaris.

    Well, most of the Solaris installations have perl installed as default. But these are usually old versions of perl. You probably need to tell the system administrator to install the latest version of Perl on the system first. And at the beginning of your perl script, include the line #!/usr/local/bin/perl -w. Change the permission of your script to executable by everyone. The Apache webserver on Unix is able to run your perl script directly, provided that the webserver is configured properly.

    The directory structure on Unix is different to DOS. So your pathnames on unix have '/' separators. One advice is when you code under Windows Active Perl, try to use '/' as path separator (windows can recognise '/').

    And also don't call windows specific modules like the Win32, etc. Only use compatible modules from CPAN if you can.

    Remember that the byte ordering is different on Sun boxes, so keep that in mind when handling binary files.

    And most importantly, build test suites to *TEST* your packages. So that when you migrate the application from Windows to Unix platform, perform something like make test will verify that the installation is working as expected. The guide for making test cases is on CPAN under Test::More and Test::Simple.

      What perl2exe is doing -> it compiles perl into opcodes, and then attaches the compiled opcode after a stub which is a PC binary file.
      No, that's not what goes on. perl2exe does some kind of xor on the sourcecode, and stuffs that at the end of the stub. No bytecode is generated. bytecode does not work reliably.
Re: perl2exe question
by teabag (Pilgrim) on Sep 23, 2003 at 13:29 UTC
    Hmmm, you might want to check out par.
    #> pp -o packed.exe source.pl # creates a self-contained binary. Modules can reside in different directories in a PAR file: / # casual packaging only /lib/ # standard location /arch/ # for creating from blib/ /i386-freebsd/ # i.e. $Config{archname} Par was tested on Win32, FreeBSD, Linux, AIX, Solaris with Perl 5.6.1 +and 5.8.0.

    It has truckloads of more options according to these pages, you might want to check out the newest version of par anyway, since it seems to do everything perl2exe does (even more I think).

    Oh, and did I mention it was free (unlike perl2exe)?

    Teabag
    Sure there's more than one way, but one just needs one anyway - Teabag

      Well the docs say..... read pxman.html Perl2Exe for Unix can generate executables for supported Unix machines. Perl2Exe for Unix can also be used from a Win32 host to generate executables for a Unix target host.
        • Perl2Exe for Unix can also be used from a Win32 host to generate executables for a Unix target host.
        AIRC it sure can. But it's NOT the same executable that you would use on yer windows systems, obviously. Probably an elf binary but I'm not sure about that.

        And as stated before you might have to change some things like paths and systemcalls.

        I'd just use the perl on your unix machine to run your script though and probably would forget perl2exe and check out par ;)

        For the record: /me is in no way associated with par, but it sounds excellent...

        Teabag
        Sure there's more than one way, but one just needs one anyway - Teabag