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.