Detect which version of perl an XS module is linked against?

Limbic~Region has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Detect which version of perl an XS module is linked against? by rafl (Friar) on Jan 02, 2008 at 23:52 UTC
You can load the xs extension using dlopen (or whatever windows has to realize that functionality - glib has g_module_open which allows to specify if symbols should be resolved lazily or not, so there has to be a way to do that on win32) and tell it to resolve all symbols non-lazily. If that fails it's probably due to some removed library. Also I wonder why those extensions are linked against libperl. I thought those are loaded from perl/libperl. At least on my unix system I couldn't find a single extension linked to libperl.	[reply]
Re^2: Detect which version of perl an XS module is linked against? by Limbic~Region (Chancellor) on Jan 03, 2008 at 00:00 UTC
rafl, Thanks for the guidance but unfortunately I need a step-by-step tutorial. Other than Inline::C, I don't have a lot of experience embedding C in Perl nor do I have any experience developing native executables on Win32. Well, aside from what I can accomplish with MinGW and Visual Basic 5 (/me ducks). Update: Thanks. Given your reply below, I will work with the #parrot team as any solution needs to be accepted as a patch. Cheers - L~R	[reply]
Re^3: Detect which version of perl an XS module is linked against? by rafl (Friar) on Jan 03, 2008 at 00:06 UTC
DynaLoader provides a dl_load_file function, which will probably do what I said above, except you don't need c or anything. Also be sure to set the PERL_DL_NONLAZY environment variable to something true to force nonlazy binding.	[reply]
Re: Detect which version of perl an XS module is linked against? by xdg (Monsignor) on Jan 03, 2008 at 00:52 UTC
Since this is a windows error, you need to determine which version of perl an XS module was linked against without loading it. Anyone have any ideas on how this might be accomplished? MSVC (2005): `> dumpbin /dependents MD5.dll [snip] Image has the following dependencies: perl510.dll KERNEL32.dll msvcrt.dll [snip]` [download] I saw a web page suggesting there may have been a "depends.exe" in some other version. MinGW (e.g. Strawberry Perl) and assuming you have grep for brevity: `> objdump -x MD5.dll \| grep "DLL Name" DLL Name: perl510.dll DLL Name: KERNEL32.dll DLL Name: msvcrt.dll` [download] -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]
Re: Detect which version of perl an XS module is linked against? by Joost (Canon) on Jan 03, 2008 at 00:19 UTC
On my linux machines all locally installed perl modules are installed in a path that includes the perl version, for instance: `$ locate Moose.pm /usr/local/lib/perl5/site_perl/5.8.8/Moose.pm /usr/local/lib/perl5/site_perl/5.8.8/Test/Moose.pm` [download] If your windows install does not have the same feature, you're probably stuck with trying to load each one and seeing if it fails. Update: maybe this link may help "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]
Re: Detect which version of perl an XS module is linked against? by BrowserUk (Patriarch) on Jan 03, 2008 at 03:10 UTC
You goofed. AS allows you to upgrade minor versions (eg. 5.8.6 to 5.8.8) without throwing away everything you previously installed as this will, mostly, work. But attempting to upgrade a major version (5.8.x to 5.10.x) and retain previously installed modules almost certainly won't. There are substantial internal changes (see the section "Changed Internals" of the 510 delta) that mean 5.8.x code will not coexist with 5.10. Your best course of action would be to delete your entire perl directory tree (which you should have done in the first place) and install 5.10 again. Your other alternative would have been to select a different path at install time (assuming you used the msi), or relocate to a different path if you used the zipped install. Note: This is not a bug in AS Perl, it is how it is designed to work. If you attempted to load an xs module compiled under 5.8.8 using 5.10 under linux, you'd run into exactly the same problem. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^2: Detect which version of perl an XS module is linked against? by Limbic~Region (Chancellor) on Jan 03, 2008 at 13:48 UTC
BrowserUk, But attempting to upgrade a major version (5.8.x to 5.10.x) and retain previously installed modules almost certainly won't. ... Your best course of action would be to delete your entire perl directory tree (which you should have done in the first place) and install 5.10 again. Note: This is not a bug in AS Perl, it is how it is designed to work. Perhaps you missed the part where I said I de-installed AS Perl 5.8.8 before installing AS Perl 5.10.0? In fact, AS Perl 5.10.0 won't let you install when it detects a previous version. Granted, I probably should have confirmed the perl directory was wiped but if AS refused to install prior to the de-install and happily agreed after, how was I to know it did not do its job correctly? Cheers - L~R	[reply]
Re^3: Detect which version of perl an XS module is linked against? by BrowserUk (Patriarch) on Jan 03, 2008 at 15:29 UTC
Perhaps you missed the part where I said I de-installed AS Perl 5.8.8 before installing AS Perl 5.10.0? No. I saw that. In fact, AS Perl 5.10.0 won't let you install when it detects a previous version. Really. That's strange because I have 5.8.6(AS811), 5.8.8(AS817) and 5.10 Beta all installed concurrently? Granted, I probably should have confirmed the perl directory was wiped but if AS refused to install prior to the de-install and happily agreed after, how was I to know it did not do its job correctly? I think it is optimistic to expect that an uninstall will remove stuff added to the install directories after the initial install. And if it did, it would prevent my being able to install a minor version upgrade over an existing install and so retain all the packages I already installed. Indeed, I think it would be disasterous for it to try and work out what you might have installed using CPAN, CPANPLUS, PPM, and all the various manual install mechanisms. I also keep a lot of Perl related stuff, additional docs, various home generated scripts and modules, and the perl sources within the overall Perl directory tree. What should it do with those? There are times when I prefer software to allow me to decide what I want to do. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^4: Detect which version of perl an XS module is linked against? by Limbic~Region (Chancellor) on Jan 03, 2008 at 15:42 UTC
Re^5: Detect which version of perl an XS module is linked against? by BrowserUk (Patriarch) on Jan 03, 2008 at 16:15 UTC
Re: Detect which version of perl an XS module is linked against? by chromatic (Archbishop) on Jan 03, 2008 at 02:15 UTC
I fixed my problem by removing the offending module but I want to fix this for everyone. That sounds like an ActiveState bug to me. I'm not sure how far to go to try to work around potentially broken Perl installations. (I'm not saying that you broke your Perl installation, only that AS Perl should be more careful.)	[reply]
Re^2: Detect which version of perl an XS module is linked against? by Limbic~Region (Chancellor) on Jan 03, 2008 at 13:40 UTC
chromatic, I agree. When I ran the de-install it obviously did not remove everything it should have. The Parrot test suite should be able to run without user interaction though (acknowledging the pop-up). We could tell each user as the problem comes up that their perl installation is broken and how to fix it or we can try to work around it. Until I researched it, I didn't know how much a work around was. Given xdg's comment, I will provide a patch in the next day or two and it can be applied or not. Cheers - L~R	[reply]