自 OS X El Capitan 以来,Apple 引入了 System Integrity Protection,它限制写入 /usr/lib /usr/bin 和其他敏感目录(甚至是 root 或 sudo 用户),这些目录由与操作系统捆绑的 Perl 安装使用系统。在安装新模块以及尝试安装 XS 模块(链接到外部 C 库的模块)时,这可能会导致问题。
因此,您不应将默认 Perl 安装视为工作开发环境,尤其是在安装自定义模块时。
查看this thread on PM 和其他人。自从 El-Capitan 之前通过从 tarball 手动构建并添加一些参数或环境变量来设置路径以来,我已经设法解决了这个问题,我认为最好保留对系统 Perl 的使用,但这不是要走的路。这使您的环境难以构建,而且对操作系统更新也很脆弱且敏感,这些更新可能会以多种不同方式破坏事物。
最佳实践似乎是从使用 brew install perl 的 Perl 开始并在此环境中工作,记住按照安装程序的指示设置 bash_profile。
还值得记住做一个brew link perl。如果您收到有关这种破坏看起来像系统 Perl 库的警告的警告 - 这些可能是您安装在顶部的模块,它会减少您链接这些的麻烦。如果您有疑虑,请记下将清除哪些模块安装,并在配置环境后重新安装它们(即您的模块安装程序方法是使用 cpanm 配置的或坚持使用旧的 perl -MCPAN -e shell 等)
brew 的这个新 Perl 设置消除了继续运行 sudo 的需要,这增加了另一层可能出错的事情,因为环境变量没有遵循并且出现权限冲突等。
最后,为了简化包/模块的安装,我建议做一个brew install cpanminus。如果您之前已经安装了这个,您可以通过执行 brew reinstall cpanminus 来确保配置路径等
如果您想更进一步,那么您也可以安装 perlbrew,这将使您能够以您的用户身份运行多个版本的 Perl,并使用他们自己的库和模块配置这些版本,这非常有用,特别是如果与您的生产环境保持一致以进行测试等。
如果从系统 Perl 迁移到这种方法,您可能会遇到一个问题,即需要处理使用 sudo 安装东西的任何遗留问题。值得花一点时间来正确设置所有这些,并且您未来的问题将大大减少,并且您不会因为担心一切都破裂而不想改变任何东西的唠叨感觉.
我也遇到过Perl Blog Article that suggests a fix for XS issues with perlbrew on Mojave
Gist 描述了更新您的 cpan shell 安装根目录,尽管这不是必需的,除非您的 cpan 在执行上述步骤后卡在旧配置中。
我也在PerlMonks上提出了这个新问题