estoy tratando de ejecutar un script Perl, pero está regresando:¿Cómo se puede determinar qué módulo Perl está causando "símbolo indefinido: Perl_Tstack_sp_ptr?"
/usr/bin/perl: symbol lookup error: /usr/local/groundwork/perl/lib/5.8.8/x86_64-linux-thread-multi/auto/IO/IO.so: undefined symbol: Perl_Tstack_sp_ptr
¿Hay alguna manera de determinar qué módulo de Perl está causando esto?
IO.so es el componente binaria de IO. Los módulos de esta distribución también forman parte de la distribución perl (es decir, tienen una vida doble).
Este tipo de error generalmente ocurre cuando se usa una versión compilada de binario utilizando una versión diferente de Perl.
Tengo un problema similar muchas veces cuando uso el antiguo módulo perl en CentOS nuevo (por ejemplo, CentOS 6.4).
/usr/bin/perl: symbol lookup error: /home/sonnn/perl5/lib/perl5/x86_64-linux-thread-multi/auto/Cwd/Cwd.so: undefined symbol: Perl_Tstack_sp_ptr
/usr/bin/perl: symbol lookup error: /home/sonnn/perl5/lib/perl5/x86_64-linux-thread-multi/auto/version/vxs/vxs.so: undefined symbol: Perl_Tstack_sp_ptr
me han resuelto estos problemas mediante: Código
Descarga fuentes de Cwd, la versión de http://search.cpan.org/ y volver a instalar
# tar -xzf version-0.9906.tar.gz
# cd version-0.9906
# perl Makefile.PL INSTALL_BASE=/home/sonnn/perl5/
# make
# make install
(If you use default module path, you can omit "INSTALL_BASE=/home/sonnn/perl5/")
No de manera similar para otros módulos
En su caso, creo que puede descargar el módulo IO desde http://search.cpan.org/ y volver a instalarlo.
Acabo de tener exactamente el mismo error "vxs" que ha publicado.Una alternativa es usar: "versión de cpam" y "cpam DBI" (DBI era el módulo que estaba teniendo problemas). Creo que es más fácil que instalar el módulo de forma manual. –
Me encontré con este problema recientemente cuando tenía una variable de entorno PERL5LIB definida en mis archivos de inicio de sesión, pero apuntaban a un directorio que era incompatible con el Perl instalado en el sistema. Esto sucedió porque el sistema de archivos HOME está montado de forma cruzada en muchas máquinas diferentes donde las instalaciones perl son heterogéneas. Eliminar la variable de entorno resuelve el problema y encontraré una forma mejor de administrar las bibliotecas locales.
Editar:
Por último, a pesar de que sé que no es responder a la pregunta, me permito ya que parece que la información realmente difícil de conseguir, porque me encontré con un montón de sitios de mencionar estos errores, pero muy pocos con soluciones consistentes en ello. Bueno, eso es todo.
No pude procesar la migración de zimbra que tenía que hacer antes de cambiar la ruta de las plataformas. Lo hemos hecho desde Ubuntu 8.04 con Zimbra 6.0.16, luego Zimbra 7.2.7, migrando a Ubuntu 10.04, luego actualizando Zimbra 8.0.9, luego migrando a Centos 7 y luego actualizando a 8.6.0
En Centos donde tuvieron que hacer un movimiento de los archivos zimbramon después de que hice ./install.sh -s ...
mv /opt/zimbra/zimbramon/lib/x86_64-linux-gnu-thread-multi/ /opt/zimbra/zimbramon/lib/x86_64-linux-gnu-thread-multi.bak
Entonces me encontré de nuevo la install.sh sin -s
Gracias. 'de hecho fue el problema. El shebang en la parte superior del guión apuntaba a la perl incorrecta. – Connor
También podría ser al revés: un binario de una versión anterior que está siendo utilizado por una versión más reciente de Perl. Por ejemplo, copiar manualmente algunos binarios de CentOS 6 a CentOS 7 (que usa una versión superior de Perl). – Nagev
Reparado. . . . . – ikegami