|
|
| Keep It Simple, Stupid | |
| PerlMonks |
Comment on |
| ( #3333=superdoc: print w/ replies, xml ) | Need Help?? |
|
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 ? I'll definitely give this some consideration. Cheers, Rob In reply to Re^9: Module::Install hacking
by syphilis
|
|