Perl Monks的交叉帖子： http://www.perlmonks.org/?node_id=1115125
我的部门需要手动编译其Perl模块，然后将其上传到网络共享文件系统，供开发人员共享和使用。我们当前的模块集是使用我的系统Perl构建的，/usr/bin/perl -V列为revision 5 version 10 subversion 1。
但是，我们有兴趣构建一个单独的Perl副本，我们也可以将其上传到网络文件系统。通过这种方式，我们无需使用我们的每台机器的Perl系统，它可以在不同的机器之间进行更改。一种“中心”Perl，可以在每台机器上标准化。
因此，我需要在我的主目录中构建Perl的本地副本。我确保安装与我的系统Perl perl-5.10.1相同的版本。我使用以下Configure后跟一个简单的make，make test，make install来完成此操作：
./Configure -des -Dprefix=/home/myuser/localperl -Duserelocatableinc
-Dprefix将其安装到我的主目录中的文件夹localperl，而-Duserelocatableinc标志使其成为@INC，如果文件夹被移动（即，上传到网络文件系统）。
当我尝试使用我的一个脚本测试它时出现问题，这些脚本需要我们手动构建的Perl模块库中的模块。我一直收到以下错误：
/home/myuser/localperl/bin/perl: symbol lookup error: .../auto/DBI/DBI.so: undefined symbol: Perl_Istack_sp_ptr
显然我的脚本使用共享的DBI模块，但是遇到了错误。通过在互联网上进行研究，人们说我需要使用新的Perl版本重新编译模块。
但是，两个Perls版本相同，并且都是在同一台机器上构建的。有人可以帮助我更好地了解阻止这些模块使用本地构建的Perl的原因吗？我尝试使用Configure设置重建本地Perl，尽可能靠近机器Perl，以尝试查看是否可行：
-Dversion=5.10.1
-Dmyhostname=localhost
-Dcc=gcc
-Dinc_version_list=5.10.0
-Darchname=x86_64-linux-thread-multi
-Dusethreads
-Duseithreads
-Duselargefiles
到目前为止，这并没有阻止错误。有没有办法让我的本地构建的Perl与使用Perl机器编译的模块一起工作，还是我必须重新编译它们并重新分发一组新的模块？
答案 0 :(得分：0)
事实证明，是，您可以重复使用具有相同版本号的不同Perl版本编译的模块。如上所述，技巧是使用尽可能接近系统Perl的./Configure标志构建localperl。您可以通过运行./Configure来确定Perl系统使用的perl -V标记。然后，您应该将这些设置与上面列出的标志一起使用。我的直觉是-Dcc=和-Darchname=是匹配的关键，但我没有时间来测试这个假设。
那么，如果我已经完成了所有这些，那么我的问题是什么，它仍然无法正常工作？简单 - 测试脚本！在我的shebang系列中，我仍然指着那天早些时候编译的Perl错误构建！ d＆＃39;哦！一旦我将脚本指向具有所有额外./Configure选项的新构建，它就能完美地运行并且能够使用所有使用Perl系统构建的模块。