|Do you know where your variables are?|
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 220.127.116.11 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 ?
I'll definitely give this some consideration.