Asker has already found a solution as of writing this, but here are some other thoughts I have were this not resolved:
Some reasons that I advocate first trying to install modules through a package manager, if you're using Perl from one:
- All dependencies (including non-Perl ones) will automatically be satisfied.
- For modules containing C code, any peculiarities in compiling for your platform will already be handled.
- If something goes wrong with using the module installed from a package manager, cleanup is easy: use your package manager's uninstall/remove command.
(If you were installing from cpan/cpanm, you would have to gather all non-Perl dependencies, and then specify any platform-specific workarounds yourself. Uninstalling Perl modules with cpanm is possible, but it is an afterthought.)
However package manager modules do have a higher chance of being outdated, since someone has to manually incorporate an update. (Or, as on many Linux distributions, there is a "feature freeze" imposed on packages, meaning that new upstream releases usually have to wait until the next OS release.)
To my knowledge, any modules installed from cpan/cpanm (e.g. path containing "site_perl") will take priority over modules installed using a package manager (path with "vendor_perl"). If a "site_perl" module is not properly installed, or is not completely uninstalled (e.g. empty directories left behind by cpanm --uninstall), your Perl program will fail to load the module in "site_perl" (because it thinks it's there), and not bother trying the module in "vendor_perl" instead; some manual cleanup might be involved if this happens.