When is the libgcc_s dependency even necessary? Gcc documents the -static-libgcc option, while saying:

There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. ...

Also, if a module depends on some small and obscure library, it might be preferable to static link with that. A la

$ make foobar LDFLAGS='-lthis -lthat -Wl,-dn,-lobscure,-dy'
[download]

When is the libgcc_s dependency even necessary?

Good point.
I wasn't sure if invoking -static-libgcc would work if perl had not been built with the same option - but I've just run a quick check (see below) and it seems that there's no problem in that regard.
So if the OP wants to distribute binaries compiled with gcc-4, but doesn't want to distribute the dll, then that's the way to go.

Actually, there's sometimes a dependency on a second dll (libstdc++-6.dll) so, to avoid having to distribute that dll, you'd also invoke -static-libstdc++.
These are linker flags, so they need to be given to $Config{ld}, which is g++ on Mingw-built perls.
As a quick test I ran:

use Inline C => Config =>
  BUILD_NOISY =>1,
  LD => 'g++ -static-libgcc',
  INC => '-IC:/MinGW/msys/1.0/local/include';

use Inline C => <<'EOC';

SV * foo(SV * x, SV * y) {
  return newSVnv(SvNV(x) * SvNV(y));
}

EOC

$x = foo(2.3, 1.1);
print $x, "\n";
[download]

Sure enough, the script ran fine and objdump revealed that the dll that was built had no dependency upon libgcc_s_dw2-1.dll:

C:\_32\pscrpt\inline>objdump -x _Inline/lib/auto/try_pl_0a36/try_pl_0a
+36.dll | grep "DLL Name"
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: perl516.dll
[download]

Whereas, if I commented out the LD => 'g++ ... assignment I then got

C:\_32\pscrpt\inline>objdump -x _Inline/lib/auto/try_pl_0a36/try_pl_0a
+36.dll | grep "DLL Name"
        DLL Name: libgcc_s_dw2-1.dll
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: perl516.dll
[download]

Cheers,
Rob

Thank you, Rob

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

1. gather dependencies in lib sub-directory
2. compile and link binary with libperl
3. 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

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

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.