Re^2: Inline::C and Dist::Zilla

Thank you, Rob

Indeed, you are right. I all need to have my portable application is:

gather dependencies in lib sub-directory
compile and link binary with libperl
run my binary to get _Inline to be generated with needed dll-files

I missed the 3rd step, because I assumed, that _Inline-stuff will be already somewhere, when I install my module

With the possible problem you described, i.e. need of the 4th step to find-and-copy gcc dll, I think I should use plain XS instead of Inline::C to have only 2 steps

WBR, basiliscos

Comment on Re^2: Inline::C and Dist::Zilla

Replies are listed 'Best First'.
Re^3: Inline::C and Dist::Zilla by syphilis (Archbishop) on Nov 14, 2014 at 14:30 UTC
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	[reply]
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]
Re^5: Inline::C and Dist::Zilla by syphilis (Archbishop) on Nov 18, 2014 at 23:12 UTC
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]