Let's say I'm building the FOO extension with my x64 gcc-4.7.0 compiler, and I put a copy of its libgcc_s_sjlj-1.dll in blib/arch/auto/FOO (alongside blib/arch/auto/FOO/FOO.dll). That works fine in most places, but if someone installs my FOO binaries on Strawberry Perl, the libgcc_s_sjlj-1.dll that I packaged never gets loaded. This happens because Strawberry Perl itself loads libgcc_s_sjlj-1.dll - only *it* will load Strawberry's 4.6.3 version of libgcc_s_sjlj-1.dll, thereby preventing the libgcc_s_sjlj-1.dll that I provided from being loaded by FOO.
Flying by the seat of my pants here -- and I have to leave for while, so verifying this will take some time -- but that shouldn't happen!
(Part of) The point of side-by-side assemblies is that, the same dll, located from different paths via the DLL Search Order, *should* allow both to be loaded without conflict. I tend to think of it -- though it is probably a simplification of the reality -- as incorporating the path into the libraries load-name.
In a nutshell, what *I think should happen* in your scenario, is that Strawberry Perl loads (say) 'c:\StrawberryPerl\bin\libgcc_s_sjlj-1.dll', and then at runtime, one of your modules loads 'c:\StrawberryPerl\site\lib\auto\Package\Name\libgcc_s_sjlj-1.dll',. And the two -- even if identical, are loaded into memory at different base addresses and -- the same or different -- everything works.
If you know different, I defer; but that's my understanding at this point.
In reply to Re^8: Module::Install hacking
by BrowserUk
in thread Module::Install hacking
by syphilis
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |