In Perl, what does this error mean?
Unresolved symbol: Perl_Gthr_key_ptr
I am getting this error while converting a Perl file to binary using perl2exe on a HP-UX PA-RISC machine.
/usr/lib/dld.sl: Unresolved symbol: Perl_Gthr_key_ptr (code) from /tmp/p2xtmp-9979/Cwd.sl IOT trap (core dumped)
Off the top of my head it looks like a non-threaded perl trying to load modules compiled for a threaded perl.
EDIT: to clarify, you can compile Perl with support for threads (threaded perl) or without support for threads (non-threaded perl). If the module was built to be used with threads and is loaded by a perl without support for threads it usually produces the above error.
To check for thread support in perl, just search for the "thread" string in the output of perl -V:
perl -V | grep thread
A Perl module is being loaded which is not binary-compatible with your base Perl installation. This can result from, among other circumstances, having previously installed modules with the CPAN shell and then using your OS package manager to upgrade Perl underneath it. This situation can be resolved by
$ cpan -r
which will find all your CPAN modules with a binary component, and recompile those binary components against your current installation of Perl.
Related
When we install module this module can ship executable which is installed into local/bin directory.
if we spy into installed script we can notice that perl version is hardcoded:
/home/user/t/local/bin/mojo
#!/home/user/perl5/perlbrew/perls/perl-5.35.1/bin/perl5.35.1
Why perl version is hard coded?
I expect it should be /usr/bin/env perl:
$ which cpanm
/home/user/perl5/perlbrew/bin/cpanm
$ cat $(which cpanm) | less
#!/usr/bin/env perl
I expect it should be /usr/bin/env perl:
In this case it would take the Perl installation currently in the path. This might be a different Perl installation compared to what was used to install the application modules. In this case running the application might fail due to missing modules. Or it might show strange behavior since the installed modules have a different version than expected by application and thus can show different behavior.
For example imagine the case when there are two perl installations at your system. And when you install script with first perl you you can not run it with second perl, because second perl lacks modules available from first one.
It should have the path of the Perl with which it was installed.
This is the perl for which its dependencies has been installed.
This is the perl with which it has been tested.
If the script was made to rely on the environment as you suggest, it could pick up a different perl, and that would very likely cause it to fail.
For example, let's take a tool which has a shebang line of
#!/home/ikegami/usr/perlbrew/perls/5.34.0t/bin/perl -w
Regardless of the environment, it works fine.
$ /home/ikegami/usr/perlbrew/perls/latest/bin/tpage \
--define USER=World \
<<<'Hello, [% USER %]!'
Hello, World!
Now let's simulate the following shebang line:
#!/usr/bin/env perl -w
It fails misearbly despite the tool being correctly installed.
$ /usr/bin/env perl -w /home/ikegami/usr/perlbrew/perls/latest/bin/tpage \
--define USER=World \
<<<'Hello, [% USER %]!'
Can't locate Template.pm in #INC (you may need to install the Template module) (#INC contains: /home/ikegami/usr/perlbrew/perls/5.28.2t/lib/site_perl/5.28.2/x86_64-linux-thread-multi /home/ikegami/usr/perlbrew/perls/5.28.2t/lib/site_perl/5.28.2 /home/ikegami/usr/perlbrew/perls/5.28.2t/lib/5.28.2/x86_64-linux-thread-multi /home/ikegami/usr/perlbrew/perls/5.28.2t/lib/5.28.2) at /home/ikegami/usr/perlbrew/perls/latest/bin/tpage line 27.
BEGIN failed--compilation aborted at /home/ikegami/usr/perlbrew/perls/latest/bin/tpage line 27.
This is an unreliable solution subject to effects at a distance. For the same reason we scope variables, we should avoid env.
The story is different for self-contained scripts, but a self-contained script wouldn't be installed using ExtUtils::MakeMaker or Module::Build (the modules setting the shebang line), so such scripts aren't relevant here.
Seems correct question to my problem was: How to prevent perl from hard coding its version at shebang?
TLDR;
export PERL_MM_SHEBANG=relocatable
After reading article #Håkon Hægland adviced and reading #38
Now I see that there is two scenario:
when script is installed into system
when script is installed into application local/bin directory.
My case is second.
So for this case I should simultaneously set environment variable PERL_MM_SHEBANG to relocatable when I set current perl into path
This env variable implemented here
I have successfully installed (i.e without errors or warnings) as per the instructions:
https://metacpan.org/pod/distribution/Lab-VISA/lib/Lab/VISA/Installation.pod
But when I try to run the example script I get:
Can't load 'C:/Dwimperl/perl/site/lib/auto/Lab/VISA/VISA.dll' for module
Lab::VISA: load_file:The specified module could not be found at
C:/Dwimperl/perl/lib/DynaLoader.pm line 190.
at C:/Dwimperl/perl/site/lib/Lab/VISA.pm line 11
Compilation failed in require at VISA Test.pl line 3.
BEGIN failed--compilation aborted at VISA Test.pl line 3.
Googling this suggests the there is something wrong with VISA.dll. This is generated during the install of the module, so I guess it is something in my environment. But my limited knowledge means I am not sure where to start. And I cannot seem to find a help contact or forum for Lab::VISA module.
It is mentioned in metacpan :
On 64-bit windows one needs a 32-bit version of perl with GNU binutils version <= 2.24. Otherwise linking with the NI-VISA library will fail. The reason for this are the following bugs in the GNU binutils:
binutils bug 16598
binutils bug 17910
These are fixed in the most recent version of the binutils. Once this version (2.26) is included in Strawberry Perl, it should be possible to use a 64-bit version of perl.
It is not possible to use either 32-bit or 64-bit versions of Strawberry Perl 5.22 as this version uses binutils 2.25.
So if you have WIN 64 , you need to install binutils
binutils bug 16598 : https://sourceware.org/bugzilla/show_bug.cgi?id=16598
and binutils bug 17910 : https://sourceware.org/bugzilla/show_bug.cgi?id=17910
Notice : don't forget to always read documentations
Since a recent update Perl fails to execute most of the scripts on my Arch Linux System.
Most of the time it failes due to a undefined Symbol in the Data::Dumper module. Other times it is because of the Parser.so with the same undefined symbol Perl_xs_apiversion_bootcheck
Perl v5.22.0
Data::Dumper is up to date (2.154).
Full Error:
/usr/bin/perl: symbol lookup error: perl5/lib/perl5/x86_64-linux-thread-multi/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_xs_apiversion_bootcheck
I already tried to reinstall the Modules, did not help.
I found this thread:
Error running Perl script on 2 different computers
They talk about the problems of differen perl versions, which I do not seem to have here.
Any other ideas? (Reinstall the perl as whole looks impossible for from here...)
Thanks
Arch Linux recently upgraded from Perl 5.20 to Perl 5.22. Those are not ABI compatible, so any XS modules installed for Perl 5.20 need to be rebuilt, or you'll get errors like the one you're describing.
Arch's perl-5.22.0-1 package includes Data::Dumper 2.158. Since you say you have 2.154, you must have manually installed an upgrade to Data::Dumper for Perl 5.20. You need to remove that (now obsolete) version.
Does pacman -Qi perl-data-dumper report anything? If it does, you might try pacman -R perl-data-dumper.
Update: It seems you've been installing modules into your system Perl directories using cpan. That winds up mixing files installed by pacman and files installed by cpan, which is why it's not recommended.
You should consider installing CPANPLUS::Dist::Arch and using cpanp instead. You can do this with:
sudo pacman -S perl-cpanplus-dist-arch
setupdistarch
After that, installing modules with cpanp will build a package file and install it with pacman. You can then use pacman to uninstall them.
I am using CentOS 5.7 perl 5.14.2. While installing CPAN module Task::Catalyst
cpan -i Task::Catalyst
i am getting the error:
http://pastebin.com/N1p1UMAH
3 modules Catalyst::Authentication::Credential::HTTP, Catalyst::View::Email and Catalyst::Plugin::Session::Store::DBIC are giving installation errors
When i tried to manually install the modules , say Catalyst::View::Email
i downloaded the tar file, and then after running the ./Makefile.pl
i got the error
http://pastebin.com/ZSDLtqii
Please suggest?
Makefile.PL is just a perl script, that is generally invoked as perl Makefile.PL, and its output is a regular 'make' style makefile.
Have a look at its contents - perhaps it's been corrupted somehow. In the case of C::V::Email, it should be 39 lines long, and look exactly like this.
I have Perl v5.10. I am trying to install Net::SSLeay 1.30 and Crypt::SSLeay 0.57.
I have already installed OpenSSL 0.9.8e.
For Net::SSLeay 1.30 I followed these steps:
perl Makefile.PL -windows C:\openssl
nmake
nmake test -- test fails
nmake install
perl test.pl
but I got an fatal error as:
D:\perl\Net_SSLeay.pm-1.30>perl -w test.pl
1..20
Can't load 'D:/perl/site/lib/auto/Net/SSLeay/SSLeay.dll' for module Net::SSLeay: load_file:The specified module could not be found at D:/perl/lib/DynaLoader.pm line 203.
at test.pl line 25
Compilation failed in require at test.pl line 25.
BEGIN failed--compilation aborted at test.pl line 25.
I got the same results for Crypt::SSLeay 0.57.
Randy Kobes has an answer for this on the Perl Win32 mailing list. Does your PATH environment variable contain the directory that contains libeay32.dll or ssleay32.dll?
There are many other answers that you can find in Google too. In cases like these, I take the whole error message and shove it into the Google search bar. I start cutting out parts of the error message, such as the specific paths, until I get some search results. This almost always works for me since I'm rarely the first person to have a problem.
Shared libs often have external dependencies, and on some operating systems those dependencies need to be immediately fulfilled when the first shared library is loaded, like your SSLeay.dll, which usually needs the two crypto libs. On linux you can check with ldd the run-time behavior, if all libs are found.
To debug this add the env var PERL_DL_DEBUG=5, like set PERL_DL_DEBUG=5 and try again or use the external tool depends.exe to see what dll's exactly are missing.
I had a similar problem with Windows Par::Packer. The resulting myprogram.exe had trouble loading rurban's hint with PERL_DL_DEBUG
Can't load 'temp\7e717f68.xs.dll' for module Crypt::SSLeay: load_file:Das angegebene Modul wurde nicht gefunden at <embedded>/DynaLoader.pm line 193.
at <embedded>/PAR/Heavy.pm line 95.
I was not able to find out which dlls to include with pp. After these hints I was simply looking to the dll-file with a hex editor and found this string: libgcc_s_dw2-1.dll - this was the dll to include into my "compiled" exe-program:
pp -M Crypt::SSLeay ^
-l c:/strawberry/perl/vendor/lib/auto/Crypt/SSLeay/SSLeay.xs.dll ^
-l c:/strawberry/c/bin/libgcc_s_dw2-1.dll ....
I'm having this same problem with a fresh install of Strawberry Perl 5.30. Googling the error just gives a bunch of unanswered, or half answered questions. Rurban is pointing in the right direction with using depends.exe. Opening ssleay.xs.dll and waiting for it to finishing throwing errors shows 5 main dll's that it depends on. 2 of which are windows core dll's, and 3 from openssl and perl. In the strawberry install, the 2 dll's related to crypto are in the [perlinstallpath]\c\bin folder. Add this to your windows %PATH% variable and it will start working.