Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

perl2exe - no more secrets

by merlyn (Sage)
on Feb 23, 2003 at 20:55 UTC ( #237943=perlmeditation: print w/replies, xml ) Need Help??

As I've said at least a few times here, the perl2exe tool is not a way to hide your source code.

Now it's even come to the attention of the security community (reported in bugtraq, for example).

For details, see the report from net-security's page.

Please stop supporting perl2exe. Please use PAR for a complete installation package, or perlcc to simply compile the top-level program.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Replies are listed 'Best First'.
Re: perl2exe - no more secrets
by gmax (Abbot) on Feb 23, 2003 at 21:37 UTC
    An interesting quote from the author of perl2exe analysis.
    See the whole paper here .
    I started to wonder why people use these Perl compilers, and then it hit me. They're obviously not used for security, since they provide no security. They're obviously not used for licence enforcement, since Bad Guys aren't going to stop to think about licences anyway, and Good Guys won't rip you off.

    They're actually used out of shame; most of the code I've seen packaged up with these things is of amazingly poor quality, and I can understand why you wouldn't want people to look at that kind of code if you're making a commercial product out of it. People don't want to expose the fact that they're selling really quite bad programs for really too much money. If these programmers had a bit more pride in their Perl abilities and a little bit more honesty with their customers, the need for these sort of "compilers" would go away, and the problem would be solved.
    (I underlined it.)

    Lessons learned
    Learn how to program properly, and forget about perl2exe!
     _  _ _  _  
    (_|| | |(_|><

      Hmm that seems to be a rather broad statement. I use perlapp since the company bought it for me. I don't create executables to hide code. My code may not be a merlyns level but I don't think it is rubish either.

      The times when I have deploy executables it is not to hide source code(you can find the source with the executable in our downloads area); it is for small utils on machines that don't need Perl installed. Especially since the people that use these machines think Perl is found on ear rings and necklaces.

      As to security issues? Security is a state of mind. Bad practices happen even if a script is not compiled.

      For example, I have found scripts that had passwords embeded in them.

        For example, I have found scripts that had passwords embeded in them.

        Im always amused when someone says something like this. My response is: so what?!

        Embedding passwords in a script is hardly automatic cause to be shot. Sure its not ideal, and there are situations where doing so would be virtually if not actually criminally negligent, but equally there are many scenarios where embedding passwords into the script itself makes quite a lot of sense. Or at bare minimum, where it does not not makes sense.

        Consider If I put my password in a ini file in the same directory as the script, is it really any more secure than the same password in the perl script that will use it? No it isn't. The basic fact is that the password will only be as secure as the OS restrictions make it. If the password is in the script and the script is readable by everyone, then you have a problem. The same problem with the ini file applies though. And you never hear anybody protesting "yeah but the password is in the inifile".

        Now before anybody says "putting a password in a file of any sort is a bad plan," I'll agree: Yup you're right. So how do you run cron jobs that need passwords? You put the password in a file? Ahah!

        Anyway, just one of my pet peeves. :-)


        <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

        • Update:  
        Just in case anybody thinks that I think that it is sane to put sensitive passwords in a perl2exe script, I dont. My point is just that putting a password into a script isn't defacto a security hole. Pretty well its never ideal to do so, but it isn't necessarily a security matter.

      Learn how to program properly, and forget about perl2exe!

      As long as this is the attitude of the Perl community, Perl will never be used for enterprise application development. I see frequent discussions asking for examples of commercial apps, large apps, and graphical apps. Granted, there are a couple examples out there but they are mostly low-profile and by most standards unsuccessful.

      What Perl needs to take it to the next level is a good native compiler. I understand why people are against this, but I believe through the increased use and associated publicity of Perl it would in fact help the oss movement more than it would hurt it.

      There are plenty of good reasons for native compilation, pretending that the only reason is to hide low-quality code is very ignorant. I'm still not sure this was your point though, so I apologize if I misinterpreted.

      Then again, you could argue Perl has found its place already and shouldn't try to expand beyond its role. I personally think world domination is a much better goal ;-).

        While you are right that many enterprise users want a perl compiler, perl2exe is not a compiler. What it gives you is an executable that contains the perl binary, required libraries, and your script. It allows you to create standalone binaries, but it does not compile your perl to a native application, it simply bundles it with an appropriate perl interpreter.

        Enterprise development? It sounds more like you're talking about packaged commercial applications. Enterprise development usually means something built in-house that is specific to a business. These days it often means putting the company's business on the web, which would not involve a compiler.

        I agree that the inability to effectively compile Perl works against it being used to build packaged commercial software, but that's a fairly unusual thing to choose Perl for. That realm seems pretty well locked up by C++. Perl is more at home on the server side, where this sort of thing is not an issue.

        A very good explanation why a "good native compiler" will not be better than the to Perl.exe utilities we already have, can be found in " Why Not Translate Perl to C?".


        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      A reply falls below the community's threshold of quality. You may see it by logging in.
      You're simplifying the argument a bit too much for my taste... What happens when you can't install perl on the target system(s) you wish to run the software on?

      Pluralitas non est ponenda sine neccesitate - mysql's philosphy
        Then you use PAR, as merlyn already pointed out.

        Makeshifts last the longest.

Re: perl2exe - no more secrets
by pg (Canon) on Feb 23, 2003 at 22:31 UTC
    This is not something one can resolve by "technology" alone.

    To hide your source code does not stop pirating any way. Most of the time, they don't care your source code at all, what they want to steal is the functionality your code delivers. What they want is money without effort, to study your source code is too long a way to go.

    Computer does not change the very nature of the human society. You go one step forward, your "friends" will go two steps forward.

Re: perl2exe - no more secrets
by tachyon (Chancellor) on Feb 24, 2003 at 12:31 UTC

    At Perlapp decompile? and A real challenge the ever industrious monks demonstrated and documented how to decompile perlapp exes by using disassembly and known plaintext attacks. While this should not be seen as an endorsement of perlapp the latest versions are not using a crappy XOR against the string 'Copyright © 2000 ActiveState Tool Corp.' and have enhanced code security using a range of measures. Of course you could probably still decompile one but the bar has been raised by ActiveState.

    Just like locks on you house it is still possible for the determined to break in. You can crack any code security device if you have the time, skill and inclination to do so. Of course you may have to RTFB. Does this make door locks bad? Of course not. They serve their purpose well enough which is to discourage the casual thief.

    Relatively speaking perl2exe exes are like a lock that can be sprung with a credit card whereas the latest perlapp's require a little more effort.

    One of Perl's major weaknesses from the point of view of the PHB is the fact that the source code is available to anyone who buys a commercial product.




Re: perl2exe - no more secrets
by belg4mit (Prior) on Feb 24, 2003 at 06:54 UTC
    I can only speak from experience but a former employer of mine insisted that most of the code I wrote (for win32, no compiling for the UN*X code) be compiled. I certainly wasn't ashamed of the code I wrote (in retrospect, maybe not ashamed, but I realize I've come quite a way). They knew that it wasn't perfect, but that didn't stop them from using obfuscators on their Java either. It's just a simple measure, like a lock on a door. As my father is fond of saying it's "to keep the honest people honest".

    I'm not belgian but I play one on TV.

      But using 'perl2exe' isn't so much a lock on a door. It's like scribbling 'this door is locked' on the door. And it gives people a false sense of security. Which is worse than having no security at all.


        It's like scribbling 'this door is locked' on the door.

        There's a door here with a sign that says "Opening this door will set off the fire alarm". There is no alarm, but since they put that sign on the door has not been opened by anyone, while before it was used as a normal exit all the time.

        If the imaginary lock looks real enough, most people won't even bother.

        - (do not use).

        That's why I use ROT-13 instead of XOR for a bogo-crypt. It's obviously a formalism only, and less likely to be confused for security.
Re: perl2exe - no more secrets
by Juerd (Abbot) on Feb 24, 2003 at 12:34 UTC

    I have nothing against perl2exe as a packager, and since that is what it is, I have nothing against perl2exe. It's a real shame people think they can hide their sources with it. It would be better if perl2exe did not conceal the source at all.

    "This allows you to create stand alone programs in perl that do not require the perl interpreter. You can also ship the executable file without having to ship your perl source code." ( is misleading.

    - (do not use).

Re: perl2exe - no more secrets
by Jenda (Abbot) on Feb 24, 2003 at 15:24 UTC

    I wonder whether the ++s were given to the node or to the name. IMO Randal is completely missing the point.

    1. From perlcc docs in Perl 5.8:

    The code generated in this way is not guaranteed to work. The whole codegen suite ("perlcc" included) should be considered very experimental. Use for production purposes is strongly discouraged.

    2. Could you tell me what do you think is the difference between what perl2exe does and what PAR does? So perl2exe uses XOR "encryption" so that the code is not plainly visible in the EXEcutable, how's that different from PAR's zipping of the data? Normal BFU doesn't see what he/she should not but anyone who knows what he's doing gets to the script&modules.

    The only difference between perl2exe and PAR is that PAR is free and you can see the source. I don't think this is a valid enough reason for this bashing.


    P.S.: Yes, it might be good if perl2exe's docs contained a remark explaining that it's possible to get the source code out of the EXE. If it was in big red letters then maybe even Randal would be happy.

      My problem with perl2exe (which you would see if you had super search'ed back) is that it gets tossed around as a solution to three problems:
      • code hiding
      • "speeding up" by "compilation"
      • bundling for single-file installation and sharing
      Well, the first two are bogus claims (especially since the exploits for the code hiding are now readily available). And the third was a nice feature, but is now completely satisfied by PAR.

      But instead of making it clear that the first two were bogus claims, they continued to take $99 from unsuspecting souls. This borders on outright lack of ethics, as far I am concerned.

      So, mostly on principle, I must continue to urge people to please stop recommending perl2exe. Use PAR.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        Yeah. If you put it like this I agree completely. The whole problem I have with your post is that you blame Indigostar for the first two. They did not make it clear enough that the 1st is not real (but they never claimed it is), and they do say the result will "run at about the same speed".

        You should not hold them responsible for someone elses faults. IMO of course.

        You are right that with PAR being available there is no real reason to use Perl2exe anymore. It was a valuable tool (though I did not use it myself. I use PerlApp and PerlCtrl) but now there is an opensource replacement.

        Anyway ... if someone asks me how to "covert a Perl script into an executable" I will mention PAR, PerlApp and perl2exe. It's his duty to choose, not mine. All I can do for him is to tell him that these three do the same thing just a little bit differently.


        Anyone who reads the docs of can see that perl2exe does not claim the first 2. It doesn't say it's hiding the code nor it claims it's speeding up the things.

        It DOES claim that you won't provide source code with the exe-distribution. This is not true as we all have read. Which is a lack of ethics, i agree.

        But i still don't understand why anyone couldn't recommend perl2exe for the functionality it DOES provide.

        Please, don't fight the windmills sir Don Quixote :-)


      Regarding your second point: PAR's zipping of files is not presented as anything other than packing several files together in a single file for convenience in delivery. It is not held out as meant for hiding anything. Using XOR (so-called) encryption only serves to obscure the source. It is a weak attempt at source code encryption, having nothing at all to do with bundling files together into a single distribution file.

      I think that that distinction is central to the "problem".


        Neither "XOR" nor "encryption" may be found in the perl2exe docs. It's just something you may find out while trying to break into the EXE. You are right that PAR is more clear about what is it doing, perl2exe doesn't say pretty much anything about what it does.

        IndigoStar says: "Perl2Exe is a command line utility for converting Perl scripts to executable files.
        This allows you to create stand alone programs in perl that do not require the perl interpreter. You can also ship the executable file without having to ship your perl source code." They do not even mention "compilation" on the page. (They do use the word a few times in the docs though.)

        IMO they did not mean the XOR as a means of real encryption, but just to prevent the text to be seen in the EXE and found by normal "Find in Files". Just a means to prevent the code from people that would have no use for it anyway.


Re: perl2exe - no more secrets
by Anonymous Monk on Feb 24, 2003 at 12:46 UTC

    I use perl2exe to deploy small packages of maintenance logic to our network users -- personally, the idea of using it for security had never crossed my mind, because I knew how it worked from the start. I use perl2exe because I haven't convinced my supervisors that we need full AS Perl installs deployed ( yet. :> ). I've tried to use perlcc, but I have yet to produce a reliable executable by any means. :/ I respect your distaste for this tool, Randal, but like any tool in the garage, it has good uses and bad uses. I can only wish that we could enforce use of screwdrivers for screws and not picking noses! ;)

    M. Howard

      used the source code: and .exe file: (perlapp) (perlcc)
        that stuff don't work.
      I can only wish that we could enforce use of screwdrivers for screws and not picking noses! ;)

      I'd rather prevent the use of non-screwdrivers for screws. Butter knives should stay on the dining room table. Try using a good cold chisel for that and I'll slap you.

Re: perl2exe - no more secrets
by benn (Vicar) on Apr 24, 2003 at 00:31 UTC
    One thing that always puzzled me on this code-hiding issue is...why bother? Not just from an open-source-is-good-for-progress point of view (although I'm a big subscriber to that too), but from the frustration that people regard source code as a 'product'. A program is much more than its source code; the product is the whole deal - manual, support, logo, pretty box, marketing concepts etc. The code is just *their* programmers' particular implementation of a bunch of solutions to the tasks proposed by the design spec.

    I would suggest that > 90% of all the code ever written is single-use applications running on a single machine, designed to do a specific task for a specific company. If it was a different task, company, or even machine, it'd be written again. And again. And again. And that's the point. Programming is about programmers, not code. If asked to write some code that duplicated/improved some existing program, how many of us would ever bother to take a glance at how the internals worked? You may look at / attempt to copy other aspects - the user interface etc., but when it actually comes down to writing the thing, you start a New File and you write your own version. Sure - there may be sticky problems to overcome, but it's *highly* unlikely that the existing program is the only code out there that addresses the issue - true this-is-so-innovative-and-radical-it's-worth-hiding stuff is very rare, and generally patented so you couldn't "steal" it anyway.

    When it comes down to it, it's about ignorance and ego. PHBs and marketing people find it had to understand unless presented with a suitable analogy - I generally use the car industry when I can (and it's amazing how far you can stretch it...). You can open the hood of your BMW and look around as much as you like. "Yup" you say..."it's an engine". If you know about engines, you can point out the bits to your friends - "Look - see how beautifully engineered that crankshaft is". You can, if you have the right tools and training, have a tinker about yourself - fix things, change things around...and if you were completely tooled up, you could even build one yourself. But you wouldn't. If you wanted a BMW, it'd be cheaper and easier to buy one. If you wanted something *better* on the other hand, and were capable of doing so,you'd already be one the same level as the Bavarian design team, and would know just as well as they do the problems you would encounter and how you'd solve them - before you even started cutting out any steel.

    Ego comes into play when you really really believe that the kit-car you knocked up in the garage is going to be a serious contender in the car world...and your engine design is soooo innovative and clever that you're going to weld that hood down *tight*..."If you want to put water and oil in it - you come to *me*!".

    I tend to treat source code as disposable - if bits of it are useful, they'll end up in a library somewhere - but a lot of that stuff is already in libraries, and most likely that's how I put the program together in the first place, because I was hired to solve a *real-world* situation - "We move bits of paper from here to here and carboard boxes from there to there - automate it". That, IMHO, constitutes the majority of 'programming' tasks - once the solution to the task is clear, the code 'writes itself'...or at least screams "this is how I'm going to be written". Once you've done a database schema, writing the queries and their presentation is more about the 'fiddly detail' than problem-solving.

    *Phew* - sorry to go on, but this again, like demerphq, this is one of my hobby-horses :) And sorry for all the car stuff - mine got broken into tonight,so that was a little pre-bedtime exorcism :)


Re: perl2exe - no more secrets
by shotgunefx (Parson) on Feb 26, 2003 at 07:28 UTC
    "Please stop supporting perl2exe. Please use PAR for a complete installation package, or perlcc to simply compile the top-level program."

    I've never used perl2exe but what's wrong with using it for the purpose of distribution as opposed to trying in vain to hide source?


    "To be civilized is to deny one's nature."
Re: perl2exe - no more secrets
by indy_singh (Initiate) on Feb 24, 2003 at 22:55 UTC
    The encryption algorithm in Perl2Exe has been improved. The current version does not use the xor method.

    The reverse-engineering method posted on bugtrack does not actually work because it assumes the xor method. It only appears to work because it reads the expected answer from the original source.

    Tools of this type are simply packagers, they don't guarantee any security of the source code or offer any speed increase.

    Perl2Exe does offer some conveniences in the distribution of applications. Because Perl2Exe is multi-platform and cross-platform it makes it easier to create binary packages for multiple OS's from a single machine.
      Comparing these two statements makes my head spin:
      The encryption algorithm in Perl2Exe has been improved.
      they don't guarantee any security of the source code
      Why? Why? If it's just a bundler, let it be a bundler. It can never be really secure, because I can always single step the program to the point where you call the Perl interpreter's "eval" method with the now-decrypted source code.

      This is looking more and more like snake oil. And since you somehow know it's been improved recently, I suspect you are an insider with the developers.

      So, why did the developers bother to increase the security? Because XOR is something a customer base can understand, but "more security" isn't? Are you only reacting to the public outcry? Would you have fixed it if it didn't show up on bugtraq? Will you upgrade it even more when (not if) it gets broken again?

      If it's truly secure, open up your methods to peer review.

      Until then, I'll stand by my statement that perl2exe is snake oil, being sold to a naive public, and that's unethical to me.

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        Why yes he is! Here is some select output from whois

        Found crsnic referral to ... Administrative Contact: Singh, Indy indy at ... Technical Contact: Singh, Indy indy at ...
        I think there's a point to (possibly trivially) cloaking something so it doesn't show up in "find in files" or other text searches, clog the disk text index with unneeded things, save accidental viewing by other people, etc.

        So my new take on it is to use ROT-13 for this "feature", so it's very clear that it's not supposed to be "encrypted" in any meaningful sence. It's more like turning a page face-down on the desk when you leave the cube, as opposed to locking it in the drawer. That's why ROT-13 was invented! That's its clearly defined purpose.


Re: perl2exe - no more secrets
by marinersk (Priest) on Sep 01, 2010 at 19:34 UTC

    I don't use perl2exe to hide anything. It solves a deployability issue where I am not allowed to install Perl on the remote system.

    I tried PAR. FAIL.
    I tried TinyPerl. FAIL.
    I tried Perl2Exe. WIN. Worked out of the box.

    I see errors I can chase down, but therein lies the rub -- It's cost me more in dollars-per-hour trying to get these "free" tools to work than I spent on my last version of Perl2Exe.

    So it looks like I will upgrade Perl2Exe and shelve getting these other, cooler, neater tools to function for me until I have some free time.

    Sample TinyPerl attempt:

    C:\Steve\Dev\psql-perl>C:\App\tinyperl\tinyperl.exe -bin psql. +exe Binary created at: psql.exe OK! Enjoy ;-P C:\Steve\Dev\psql-perl>psql.exe Can't find or load LibZip: ERROR: No filename given Perl lib version (v5.8.0) doesn't match executable version (v5.8.9) at + (eval 1) line 28.

    Sample PAR attempt:

    C:\Steve\Install\PAR\PAR-Packer-1.006>dir Volume in drive C is CBoot Volume Serial Number is B4AB-1A65 Directory of C:\Steve\Install\PAR\PAR-Packer-1.006 09/01/2010 12:38 PM <DIR> . 09/01/2010 12:38 PM <DIR> .. 06/13/2010 11:10 AM 394 AUTHORS 06/26/2010 05:02 AM 48,710 ChangeLog 09/01/2010 12:38 PM <DIR> contrib 09/01/2010 12:38 PM <DIR> inc 09/01/2010 12:38 PM <DIR> lib 06/19/2010 11:50 AM 4,643 Makefile.PL 06/26/2010 05:18 AM 1,829 MANIFEST 06/19/2010 11:50 AM 451 MANIFEST.SKIP 06/26/2010 05:04 AM 745 META.yml 09/01/2010 12:38 PM <DIR> myldr 06/26/2010 05:18 AM <DIR> package 06/13/2010 11:10 AM 5,846 README 09/01/2010 12:38 PM <DIR> script 09/01/2010 12:38 PM <DIR> t 06/13/2010 11:10 AM 185 TODO 8 File(s) 62,803 bytes 9 Dir(s) 4,356,517,888 bytes free C:\Steve\Install\PAR\PAR-Packer-1.006>perl Makefile.PL *** You have extra Perl library paths set in your environment. Please note that these paths (set with PERL5LIB or PERLLIB) are not honored by perl when running under taint mode, which may lead to problems. This is a limitation (by design) of Perl, not of PAR::Packer; but some of the problems may manifest here during installation. Checking if your kit is complete... Looks good Warning: prerequisite Getopt::ArgvFile 1.07 not found. Warning: prerequisite Module::ScanDeps 0.96 not found. Warning: prerequisite PAR 1.000 not found. Warning: prerequisite PAR::Dist 0.22 not found. Warning: prerequisite Parse::Binary 0.04 not found. Warning: prerequisite Win32::Exe 0.14 not found. Note (probably harmless): No library found for oldnames.lib Note (probably harmless): No library found for kernel32.lib Note (probably harmless): No library found for user32.lib Note (probably harmless): No library found for gdi32.lib Note (probably harmless): No library found for winspool.lib Note (probably harmless): No library found for comdlg32.lib Note (probably harmless): No library found for advapi32.lib Note (probably harmless): No library found for shell32.lib Note (probably harmless): No library found for ole32.lib Note (probably harmless): No library found for oleaut32.lib Note (probably harmless): No library found for netapi32.lib Note (probably harmless): No library found for uuid.lib Note (probably harmless): No library found for ws2_32.lib Note (probably harmless): No library found for mpr.lib Note (probably harmless): No library found for winmm.lib Note (probably harmless): No library found for version.lib Note (probably harmless): No library found for odbc32.lib Note (probably harmless): No library found for odbccp32.lib Note (probably harmless): No library found for msvcrt.lib Writing Makefile for the par.exe program Writing Makefile for PAR::Packer C:\Steve\Install\PAR\PAR-Packer-1.006>nmake Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. C:\Perl\bin\perl.exe "-Minc::Module::Install" -e "extract_par +(q(PAR-Packer-1.006-MSWin32-x86-multi-thread-5.8.9.par))" cp lib/App/Packer/ blib\lib\App\Packer\ cp lib/PAR/ blib\lib\PAR\ cp lib/PAR/Filter/ blib\lib\PAR\Filter\ cp lib/PAR/Filter/ blib\lib\PAR\Filter\ cp lib/PAR/StrippedPARL/ blib\lib\PAR\StrippedPARL\ cp lib/PAR/ blib\lib\PAR\ cp lib/PAR/Filter/ blib\lib\PAR\Filter\ cp lib/PAR/StrippedPARL/ blib\lib\PAR\StrippedPARL\Dynamic.p +m cp lib/PAR/Filter/ blib\lib\PAR\Filter\ cp lib/ blib\lib\ cp lib/PAR/Filter/ blib\lib\PAR\Filter\ cp lib/PAR/StrippedPARL/ blib\lib\PAR\StrippedPARL\ C:\Steve\Utils\nmake.exe -f Makefile all -nologo C:\Perl\bin\perl.exe sha1.c.PL sha1.c cl -c -Zm1000 -nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D +_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTO +M IZE -DPRIVLIB_LAST_IN_INC -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS +-DUSE_PERLIO -DPERL_MSVCRT_READFIX -I"C:\Perl\lib\CORE" -DPARL_EXE= +\ "parl.exe\" -MD -Zi -DNDEBUG -O1 main.c The system cannot execute the specified program. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code + '0x1' Stop. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code + '0x2' Stop. C:\Steve\Install\PAR\PAR-Packer-1.006>
      every one knows that a good perl programmer can do in a few lines of code, that would take other languages many pages this is because of all the hard work put into the high level language by the open source community, so a perl compiler needs to look at the machine code or the assembly code or in reality a perl to NASM converter to get a good compilation and allow to be used on many operating systems. not to mention the creative ways to use jump statements to reduce the amount of code in a program... is any one ready to work on this ???
Re: perl2exe - no more secrets
by Anonymous Monk on Feb 25, 2003 at 22:46 UTC
    I'm trying to compile PAR under cygwin. I've downloaded the source to perl.5.8.0-1 from cygwin, and rebuilt it using the When I try to compile PAR, I get the following errors. I end up with a par.dll instead of a par.exe. Can anyone give me pointers on getting it installed? Thanks
    $ perl Makefile.PL Writing Makefile for the par.exe program Writing Makefile for PAR $ make cp PAR/ blib/lib/PAR/ cp blib/lib/ make[1]: Entering directory `/usr/src/PAR-0.63/myldr' gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/lib/perl5/5 +.8.0/cygwin-multi-64int/CORE main.c ld2 main.o -s -s -s -L/usr/local/lib /usr/lib/perl5/5.8.0/cygwin-mul +ti-64int/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.0/cygwin-m +ulti-64int/CORE -lperl -lutil -o par.exe gcc -shared -o par.dll -Wl,--out-implib=libpar.dll.a -Wl,--export-all +-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ main.o -s -s -s -L/usr/local/lib /usr/lib/perl5/5.8.0/cygwin-multi-64i +nt/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.0/cygwin-multi-6 +4int/CORE -lperl -lutil Creating library file: libpar.dll.a ./par.exe -I../blib/lib -I/usr/lib/perl5/5.8.0/cygwin-multi-64int -I/u +sr/lib/perl5/5.8.0 -I/usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64in +t -I/usr/lib/perl5/site_perl/5.8.0 -I/usr/lib/perl5/site_perl -I/usr/ +src/PAR-0.63 -I. -B -O../script/parl.exe make[1]: *** [../script/parl.exe] Error 255 make[1]: Leaving directory `/usr/src/PAR-0.63/myldr' make: *** [subdirs] Error 2 $
      The DLL-creation problem has been solved with PAR 0.66, but Cygwin's executable format doesn't seem to like arbitary data appended to it (altough a self-contained script made with '' plus a 'perl.exe' works well); I'm working with the list and Mattia to find a solution. (See related discussions.)

      Meanwhile, MSYS+MinGW might be your best bet, and PAR is known to run well on that platform.

      Update -- PAR 0.67 has been released and offers complete cygwin support. Much rejoice!
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://237943]
Approved by scain
Front-paged by scain
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2023-12-05 08:05 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (26 votes). Check out past polls.