| Subject: | Workaround for buggy behavior in CBuilder |
Howdy!
This might be a tad annoying, since your module does nothing wrong, but ExtUtils::CBuilder has a bug on platforms that define DynaLoader::mod2fname (VMS, OS2 and Android by default. In the future, possibly anything) that you'll have to work around for Module::Crypt to work on those.
Some background. What mod2fname does is tweak the library name that CBuilder/Makemaker/etc produces. For example, on Android, Hash/Util/Util.so becomes Hash/Util/PL_Hash__Util.so; on VMS it's practically the same thing but with a different extension.
The bug manifests is a couple of a different ways; for VMS, $cbuilder->lib_file(...)/$cbuilder->link() returns a library name different than what DynaLoader would try looking for. On OS2, $cbuilder->lib_file(...) returns a different name than what $cbuilder->link(...) does, even if you call it as $cbuilder->link(lib_file => $cbuilder->lib_file(...)).
The workaround is pretty simple: Remove the explicit call to ->lib_file and the lib_file parameter to link, and let ->link() compute it on its own. That should get M:C working on all three platforms, but only on perl 5.20+.
On the other hand, if you want to have M:C working on VMS with older perls, you'll have to use your own version of lib_file, ala this: http://perl5.git.perl.org/perl.git/blobdiff/374516c223a92d1e2e36ba1fce31523e234cc499..598cd34e1e9b9e41360ee32971caf8ae799cc259:/dist/ExtUtils-CBuilder/lib/ExtUtils/CBuilder/Base.pm
(but keep in mind that that branch hasn't been merged into the perl core, so it might change)