in reply to Re^9: Module::Install hacking
in thread Module::Install hacking
It seems that the rot set in somewhere between 806 and 827.
I wonder if that came about with the advent of -f don't do $sitelib/sitecustomize.pl at startup?
I have still yet to find the logic behind that addition.
I would've thought that anyone who installs ActivePerl and accepts the default installation procedure of having the path modified appropriately would find that perl/site/bin would be in the path.
Hm. Do I routinely accept that? I don't remember, but my gut reaction is "probably not". What I can say is I have never see perl/site/bin in my path... {shrug} Maybe I'm just ultra-cautious.
FWIW: I have made the SxS thing work. I'm considering posting the details here, but as it is all C/windows and no Perl, they'll probably be some hue and cry about it being off-topic and it might get considered and deleted. Despite its obvious application to Perl-related issues.
In a nutshell:
- MyApp.exe uses MyDll.dll uses Dep.dll.
- It call depFunc() (from Dep.dll) which is takes params (int, double).
- ext\ExtDll.dll uses ext\Dep.dll.
- At runtime, MyApp.exe runtime dynamically loads ext\MyDll.dll.
- It then calls boot() (from ExtDll.dll) which in turn calls depFunc() (from ext\Dep.dll), but this time it takes (int, int).
And both Dep.dlls get loaded and the correct functions called in both cases:
C:\test\myApp>depends64 -c -pb -of MyApp.depends MyApp.Exe ext\ExtDll. +dll C:\test\myApp>type MyApp.depends [ ,,, snip loads ... ] Started "c:\test\myapp\MYAPP.EXE" (process 0x840) at address 0x0000000 +140000000. Successfully hooked module. Loaded "c:\windows\system32\NTDLL.DLL" at address 0x0000000077A50000. + Successfully hooked module. Loaded "c:\windows\system32\KERNEL32.DLL" at address 0x000000007792000 +0. Successfully hooked module. Injected "c:\perl64\bin\DEPENDS.DLL" at address 0x0000000073B00000. + **1** Loaded "c:\test\myapp\MYDLL.DLL" at address 0x0000000180000000. Succe +ssfully hooked module. Loaded "c:\test\myapp\DEP.DLL" at address 0x0000000000150000. Success +fully hooked module. Entrypoint reached. All implicit modules have been loaded. LoadLibraryExA("ext\ExtDll.dll", 0x0000000000000000, 0x00000000) calle +d from "c:\test\myapp\MYAPP.EXE" at address 0x000000014000103F. Loaded "c:\test\myapp\ext\EXTDLL.DLL" at address 0x0000000000180000. +Successfully hooked module. Loaded "c:\test\myapp\ext\DEP.DLL" at address 0x00000000001B0000. Suc +cessfully hooked module. **2** LoadLibraryExA("ext\ExtDll.dll", 0x0000000000000000, 0x00000000) retur +ned 0x0000000000180000. Error: The Side-by-Side configuration information for "c:\test\myapp\e +xt\EXTDLL.DLL" contains errors. The application has failed to start b +ecause its side-by-side configuration is incorrect. Please see the ap +plication event log for more detail (14001). GetProcAddress(0x0000000000180000 [c:\test\myapp\ext\EXTDLL.DLL], "boo +t") called from "c:\test\myapp\MYAPP.EXE" at address 0x00000001400010 +92 and returned 0x0000000000181000. Exited "c:\test\myapp\MYAPP.EXE" (process 0x840) with code 0 (0x0).
The important bits are **1** and **2** that show that two different dlls called Dep.dll are loaded into the same process.
Harder to fathom is Error: The Side-by-Side configuration information for "c:\test\myapp\ext\EXTDLL.DLL" contains errors. line, but it doesn't stop the process completing successfully or prevent the correct depFunc() being called.
Should I post this? (If you think of MyApp.exe as Perl.exe; MyDll.dll as Perl5X.dll; ExtDll.dll as a XS modules dll; and Dep.dll as a C/C++ runtime dependency of both perl5x.dll and an XS modules .dll; then the logic is clearly "perl-related", but given the recent naziism about OT posts ...