in reply to Re^3: Perl_croak_xs_usage problem
in thread Perl_croak_xs_usage problem

Well, print "hello\n" is enough to create the error msg I would send the .par if I could figure out how to stick it in here! pp --version Set up gcc environment - 3.4.5 (mingw-vista special r3) PAR Packager, version 0.991 (PAR version 0.994) perl -v This is perl, v5.10.1 built for MSWin32-x86-multi-thread Where to go from here ?

Replies are listed 'Best First'.
Re^5: Perl_croak_xs_usage problem
by BrowserUk (Patriarch) on Oct 01, 2009 at 21:00 UTC
    Well, print "hello\n" is enough to create the error msg

    Really? 

    C:\test>perl -e"print qq[Hello world\n]"
Hello world

    [download]

    Hm. No error message. What did I do wrong.

    What perl did you have installed when you packaged the .par file? Is is possible that as a part of that packaging the .par file, you packaged up one or more dlls that are incompatible with your current Perl installation? And therefore when you run that .par, it unpacks that incompatible dll in such a way that it is found in preference to the equivalent dll that shipped with the installed version of perl?

    In response to my explanation of how to discover which dll is the cause of the error, you told us

    Just come from re-installing... No change! :-(

    What did you reinstall?

    1. The same version of Perl--why would that make things change?
    2. The same pre-packaged .par file--ditto!
    3. Both?
    4. The OS?
    5. The carburetor on your motorbike?
    Where to go from here ?

    My suggestion would be to grab Process Explorer. Then re-run the .par file and when the error dialog with the error message is on-screen, switch to ProcExp and select "view->Lower Pane View->dlls", and "View->Show Lower Pane".

    Then select the perl process running the .par file and click in the lower pane. Scroll the pane to the bottom and you will see all of the dlls being used by that process. If you mouse over perl510.dll you will get a tooltip showing you the full path to the dll that is failing to fulfill the Perl_croak_xs_usage() entrypoint.

    I suspect that this will show that the perl510.dll in question is being unpacked from the .par file and is being loaded in preference to the perl510.dll that comes with your AS distribution. This is guesswork, but is the only thing I can think of (in the absence of the .par file and your installation), that might produce the symptoms you are describing.

    You need to put some effort in and do some investigation. Saying print "hello\n" is enough to reproduce the problem belies the fact **THAT I HAVE AN ENTIRLEY DIFFERENT SET UP TO YOU AND THERFORE IT DOES NOT REPRODUCE ...

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      Sorry, dumpbin did not work on my system... It would have shown me no different output than yours, I guess.

      I use PAR (a Perl module) to package some "pl" and "pm" files to one "exe" file. There is no "par" file involved. Nevertheless PAR creates a "par" file. For me, this means, that there is no "par" file containing any dll as far as I know.


      I looked at the Process Explorer. I found:
      ->cmd.exe
         ->perl.exe
            ->parlIlTc.exe
               ->parlIlTc.exe

      perl.exe has the correct dlls, as well as the first parlIlTc process. The last process has C:\WINNT\Temp\par-li04870\cache-5c8d934cadf7f43c5d1b5b758a47dff329f59ea8\perl510.dll, though!

      Might there be an error within PAR?
[reply]
[d/l]
[select]
        Might there be an error within PAR?

        You'd have to consult PAR maintainers as to whether they consider it a error. I suspect that they'll say that you are using it wrongly.

        When you package up your scripts with PAR, it not only incorporates your scripts and modules, but also as much of the installed perl--including any required DLLs--as is required to allow your script to run on a machine that does not have a perl installation. The intention being that you can distribute that single file to users and not require them to install Perl before using your code.

        What you are attempting to do is run that packaged application on a system that already has a full perl installation. And a different version of Perl to that which was used during the packaging. Hence you are creating a situation whereby there are multiple executable files (dlls) with the same name but differing contents being loaded at runtime. Needless to say, this doesn't work.

        Essentially, you have discovered that my guess regarding the presence of an incompatible version of perl510.dll exists within your .par file is correct. You now need to decide what to do about it. If you contact the PAR maintainers they might have a work-around?

        The simplest solution would be for you to install the appropriate parts of your application--ie. just your sources files (.pls and .pms)--onto the system manually (by copying the files from the original system), and then, if necessary, repackage the application on the new system using PAR.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom