Maybe you should bring this up with the Mingw folks, both of them, since they have a ugly fork war right now. DLLs should always be backwards compatible if their names are the same. That is the expectation of Microsoft Windows.

Another random idea, why not create a Perl module whose only purpose is to install that particular Mingw DLL?

DLLs should always be backwards compatible if their names are the same

Yes - I think this was a case of needing forwards compatibility.That is, build a module that uses the gcc-4.7.0 version of libgcc_s_sjlj-1.dll, then run it with the gcc-4.4.3 version of the same dll and we got a missing entry point in relation to __addtf3.

I'm going to check this out again when I can get hold of strawberry perl 5.14.2.1 64bit.I currently have the 5.16.0 version of Strawberry (gcc-4.6.3), and there's apparently no such incompatibility between its libgcc_s_sjlj-1.dll and gcc-4.7.0's.

Another random idea, why not create a Perl module dedicated whose purpose only purpose is install that particular Mingw DLL?

Sounds good to me. It wouldn't help wrt the problem of perl/site/bin not being in the path, but it would ultimately avoid the need to use --force.Apart from writing and uploading the module, I would just need to alter the ppd files and package.xml (to specify this additional dependency) - which could be done programmatically. The actual binaries that are already on the repo don't need amending.The module should, I guess, be under the PPM namespace. Would PPM::Sisyphusion suffice as a name ? Is there something better ?

Sounds good to me. It wouldn't help wrt the problem of perl/site/bin not being in the path, but it would ultimately avoid the need to use --force.Apart from writing and uploading the module, I would just need to alter the ppd files and package.xml (to specify this additional dependency) - which could be done programmatically. The actual binaries that are already on the repo don't need amending.The module should, I guess, be under the PPM namespace. Would PPM::Sisyphusion suffice as a name ? Is there something better ?

I'll definitely give this some consideration.

I've seen the Alien:: package used for C libraries, not sure if object files or executable files, of course ask module authors list if you are not sure. I'm not sure if there is a certain API that Alien:: modules have or not. My only experience with Alien::wxWidgets and I want to forget I ever had to use it (A::W demands to build Wx C++ libs from source, VC Wx only has a VS IDE Solution, no nmake makefile). I can't really help you much further the idea I proposed, I've never done with my eyes, and I dont know how feasible it is. It somehow sounds logical since the "Module" can get new CPAN releases to distribute bug fixes of that particular DLL. The DLL name is obviously versioned to a certain ABI unless you write your own libgcc.a that will LoadLibraryEx and GetProcAddress everything.