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

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.
RIP PCW It is as I've been saying!(Audio until 20090817)

Replies are listed 'Best First'.
Re^6: Perl_croak_xs_usage problem
by markuhs (Scribe) on Oct 02, 2009 at 06:07 UTC
    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]
        It happens during "packaging time" not during "run time"... The system stays the same all the time. (Not for later usage! But I currently do NOT reach the point, where I can deploy it as a tool to other users/systems.)

        I downgraded to active state build 1005 and it works again...
[reply]
        Also, it would be good idea to first test your pp'd file locally by removing perl from path, something like 
        C:\>set path=%windir%\system32;%windir%
C:\>mypp.exe

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom