in reply to
Re^3: Module::Install hacking
in thread Module::Install hacking
BrowserUk established that the crash was occurring in the libgcc_s_dw2-1.dll ... and that piece of information made the job of fixing the problem so much easier.
Most of my ppm packages have a dependency on libgcc_s_dw2-1.dll, so I therefore distribute that file with them.
However, I don't like the idea of installing that dll into a path folder (which is where it needs to go) - given that there could well be other instances of that dll elsewhere in the path, thereby causing some incompatibility.
So, I rename a copy of libgcc_s_dw2-1.dll to libgcc_sis_452.dll, have the module look for that dll instead, and distribute (in blib/script of the ppm package) libgcc_sis_452.dll instead of libgcc_s_dw2-1.dll. (I also take a similar approach with libstdc++-6.dll which I've renamed to cpp+-6_sis.dll, but I distribute that file only with the few packages that actually need it.)
I guess because of the crash that BrowserUk identified (details of which are not posted in this thread), the question of ABI comes up. I dont have copy of libgcc_s_dw2-1.dll in my Strawberry Perl folder, but I found libgcc_s_sjlj-1.dll. I think it is identical to libgcc_s_dw2-1.dll. Here are its exports.
Looks like it implements non-CPU-native math, and it implements GCC's C++ compliant exception handling. AFAIK, GCC's exception handling is not SEH/MS compliant. Note, I dont know the details on the post preprocessor or asm level of GCC exception handling. The question is, will the 2 different libgcc DLLs every try to pass a struct to each other, or use the same TLS slot, use the same Kernel32 Event, or see each other, or not see each other, for example, this line is MS DLL dependent, it lives in libgcc http://opensource.apple.com/source/llvmgcc42/llvmgcc42-2335.9/gcc/config/i386/cygming-crtbegin.c