in reply to Re^2: Inline::C and Dist::Zilla
in thread Inline::C and Dist::Zilla

I think I should use plain XS instead of Inline::C to have only 2 steps

If you're going to compile the XS module using gcc-4 before sending it to the various client PC's then you still leave yourself open to the very same dll-dependency problem.

If you compile with gcc-3 it won't be a problem (though this is a poor reason for using gcc-3 instead of gcc-4 imo) ... or if you just distribute the source to the client PC's and leave the XS compilation to be done on those client machines then you also avoid the issue.

Even if you were to compile the XS component using a post-MSVC++6 Microsoft compiler you would strike a similar problem in that the compiled code would depend upon a runtime library that might not be present on the client PC.

However, I don't think you should worry too much about these issues. They are solvable and you'll soon work out what needs to be done if they jump up and bite you.
The good news is that whenever a dll is not found, the error message (pop-up) gives you the name of that dll.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Inline::C and Dist::Zilla
by basiliscos (Pilgrim) on Nov 18, 2014 at 22:03 UTC

    Thank you, syphilis

    Yep, I have gathered depend DLLs when noisy popup appears. They are located at the same directory where is my-binary.exe.

    Is there any way to hide them in some sub-directory?

    PS. I have added linker flags: 

     -static-libstdc++ -static-libgcc

    [download]

    , but that helped me not: I'm still forced to ship libstdc++-6.dll and libgcc_s_dw2-1.dll

    WBR, basiliscos.
[reply]
[d/l]
      Is there any way to hide them in some sub-directory?

      They just need to be either in the same directory as the dll that needs them, or a directory that's in the path.
      If you want to put them in some sub-folder that's not necessarily in the path, it *might* (untested) work if your Inline::C script were to start with: 
      BEGIN {
 $ENV{PATH} .= ";.\\wherever\\they\\are;"
};

      [download]
      It seems odd that you're still forced to ship those 2 dll files. You did add those flags to 'g++', and not 'gcc' ?
      If you build your script with BUILD_NOISY you'll be able to check the output to see that they were present when the g++ command was run.
      The other thing you can do is to check that the Inline::C dll doesn't contain a dependency on either of those 2 gcc dlls: 
      objdump -x your_I-C.dll | grep "DLL Name"

      [download]
      If the output of that mentions either of the 2 gcc dlls, then the Inline::C build wasn't done right.
      And if the output does *not* mention either of the 2 gcc dlls, but you still need to ship them, then it must be some other dll that depends upon them. (If you're not shipping any other dlls then perhaps there's something wrong with the path setting on the client machine.)

      Cheers,
      Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom