Re^8: Module::Install hacking

[BrowserUk]

Surely $Config{installsitebin} should be in the path - even if no such directory exists initially.

I'd never even heard of $Config{installsitebin} prior to this discussion. I've no idea where it comes from or who invented it. From a quick google, it appears to be modelled after /usr/sbin, and therefore completely alien to Windows.

I've no idea how I (as an (AS)Perl user) would ever think to add a random directory, that isn't mention anywhere, to my path; especially if it doesn't exist (yet).

As a programmer, I would steadfastly NOT add a non-existent directory to my path. And as a matter of course, I routinely trim my path to containing just those directories that contain things I use.

All I'm doing is having PPM overwrite an existing file (installed by a previous 'ppm install') with an *identical* file.

I agree that needing --force to overwrite identical files is stupid.

But I also think that given that you are incorporating a version into your renamed DLLs, there is no need to use installsitedir. Nor to make the names unrecognisable either.

If you renamed your package-attached version of libgcc_s_dw2_1.dll to libgcc_s_dw2_1.nnn.dll, I think that they could all (libgcc_s_dw2_1.dll; libgcc_s_dw2_1.463.dll; libgcc_s_dw2_1.471.dll etc.) be put into perl\bin and coexist there without conflict, and without needing the extra directory or further additions to the path.

But, having failed to make the SxS thing work -- though I'm pretty certain I did when I first investigated the issue 3 or 4 years -- I'm not suggesting you pursue this any further. In fact, I strongly recommend against it on the basis that I have no desire to send you down any further dead ends.

But still the nagging doubt that what you have now, is repeating the mistakes of the past, persists. But I can live with that.

So, once again, sorry for the misdirection; I hope that overall I helped more than hindered.

[syphilis]

I'd never even heard of $Config{installsitebin} prior to this discussion

As I understand it, EU::MM (and PPM) examine the values of $Config{install*} to determine where the files in blib get installed.
Both installsitescript and installsitebin appear to be of particular relevance when deciding where files in blib/script should be installed.

With my mingw-built perls, there's no site/bin specified by %Config, so anything in blib/script (sanely) ends up in perl/bin.
But, for some reason, ActiveState set their %Config in such a way that anything in blib/script ends up in perl/site/bin.

With build 806 of ActivePerl:

C:\_32>perl -V:installsite.*
installsitearch='C:\_32\ap806\site\lib'
installsitebin='C:\_32\ap806\bin'
installsitelib='C:\_32\ap806\site\lib'

With build 827 of ActivePerl:

C:\_32>perl -V:installsite.*
installsitearch='C:\_32\ap827\site\lib';
installsitebin='C:\_32\ap827\site\bin';
installsitehtml1dir='';
installsitehtml3dir='';
installsitelib='C:\_32\ap827\site\lib';
installsiteman1dir='';
installsiteman3dir='';
installsitescript='C:\_32\ap827\site\bin';

It seems that the rot set in somewhere between 806 and 827.

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. (At least, that ought to be the case - given the way they've set up their %Config.)
It'd be a bit of a hassle for me to check on that behaviour - so I won't.

I've had no feedback (apart from yours) suggesting that there has been any problem associated with files being installed into perl/site/bin - though, of course, there are all sorts of reasons that explain the absence of such feedback ;-)

I think that they could all (libgcc_s_dw2_1.dll; libgcc_s_dw2_1.463.dll; libgcc_s_dw2_1.471.dll etc.) be put into perl\bin and coexist there without conflict, and without needing the extra directory or further additions to the path.

The only way of getting them into perl/bin on these current builds of ActivePerl is, afaik, to run a post-install script.
I guess that, too, is do-able in such a way that it doesn't cause annoyance to the user. I could have it such that every ppm install downloads the post-install script, but then that script exits immediately if the files that it would otherwise install are already in place.
This would require that all of the binaries would need to be rebuilt. (Lotta work for me.)

I hope that overall I helped more than hindered

No problems in that regard ;-)

Cheers,
Rob

[BrowserUk]

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
[phone].  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 ...

blockquote

[bulk88]

You have written SxS lectures before here, Re: [OT][Win32] How to load the right dll, so why not post your latest example?

TLDR: post it.