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
Related
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.
When I try to install Padre with cpan (or cpanm)...
bash-4.2$ sudo cpan Padre
...
CPAN.pm: Building P/PL/PLAVEN/Padre-1.00.tar.gz
Found locale ru_RU.UTF-8
Found wxWidgets 2.8.12
Found Wx.pm 0.9921
Unparsable version '6,59' for prerequisite ExtUtils::MakeMaker at inc/Module/Install/Makefile.pm line 352.
Checking if your kit is complete...
Looks good
unexpected end of string while parsing JSON string, at character offset 281 (before "},"build_requires":{...") at /usr/local/share/perl5/CPAN/Meta/Converter.pm line 45.
at /usr/share/perl5/vendor_perl/ExtUtils/MM_Any.pm line 831.
ERROR from evaluation of /root/.local/share/.cpan/build/Padre-1.00-UsByhx/winxs/Makefile.PL: unexpected end of string while parsing JSON string, at character offset 78 (before "}") at /usr/local/share/perl5/CPAN/Meta/Converter.pm line 45.
Warning: No success on command[/usr/bin/perl Makefile.PL]
PLAVEN/Padre-1.00.tar.gz
/usr/bin/perl Makefile.PL -- NOT OK
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
Could not read metadata file. Falling back to other methods to determine prerequisites
This bug we have a few years. I can't find JSON, that was a reason of this error. Anybody pass this problem?
There are known problems in some releases of JSON::PP which cause problems further up the toolchain like this.
Try upgrading JSON::PP. If the toolchain issues prevent you from installing JSON::PP in the normal way, then download the latest version of the module from CPAN, and manually replace the JSON/PP.pm file on your system.
Fedora currently has Padre 0.90 available as a pre-built package. So you can install it with
$ sudo yum install perl-Padre
I'm trying to install Bugzilla but encounter a Perl problem.
When installing required Perl modules, I get the following error message:
ERROR: Using install-module.pl requires that you install a compiler, such as gcc.
gcc 4.2.3 is installed and in the path. I'm using perl v 5.8.6 OS: Linux DiskStation 2.6.32.12
Another thread on Stackoverflow refers to PerlGcc but it seems to work on Solaris only.
How can I make Perl find gcc?
I'm guessing you're talking about this thread. Assuming that the guy talking about the version of gcc being relevant was onto something, could you check that you don't have an older version of gcc lying around somewhere higher in the path with
$ which gcc
I am trying to get WWW::Mechanize to login to Yahoo using https; however, it requires the use of Crypt::SSLeay for sending over https.
Crypt::SSLeay installed succesfully, and openssl was already installed on the system.
However, it gives the error upon loading:
Can't load '/home/gen19/perl5/lib/perl5/lib/site_perl/5.10.1/i686-linux//auto/Crypt/SSLeay/SSLeay.so' for module Crypt::SSLeay: /home/gen19/perl5/lib/perl5/lib/site_perl/5.10.1/i686-linux//auto/Crypt/SSLeay/SSLeay.so: undefined symbol: PL_sv_undef at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
at /home/gen19/lwp4 line 15
Compilation failed in require at /home/gen19/lwp4 line 15.
BEGIN failed--compilation aborted at /home/gen19/lwp4 line 15.
The installation of Crypt::SSLeay was successful, and could recognize the installation of openssl (here):
perl Makefile.PL
=======================================================
Only one OpenSSL installation found at /usr
Consider running 'perl Makefile.PL --default' the next
time Crypt::SSLeay is upgraded to select this directory
automatically thereby avoiding the following prompt.
=======================================================
Which SSL install path do you want to use? [/usr] /home/gen19/ssldir
BUILD INFORMATION
================================================
ssl library: OpenSSL 0.9.8 in /home/gen19/ssldir
ssl header: openssl/ssl.h
libraries: -L/home/gen19/ssldir/lib -lssl -lcrypto -lgcc
include dir: -I/home/gen19/ssldir/include/openssl -I/usr/kerberos/include
================================================
Note (probably harmless): No library found for -lgcc
Writing Makefile for Crypt::SSLeay
The test suite can attempt to connect to public servers
to ensure that the code is working properly. If you are
behind a strict firewall or have no network connectivity,
these tests may fail (through no fault of the code).
Do you want to run the live tests (y/N) ? [N]
NOTE: recently installed Perl v5.10.1 using App::perlbrew, due to LWP::UserAgent's needing it. I installed Crypt::SSLeay using my new version of Perl.
I don't have root priveldiges, as I am doing this on a remote server at school. Please tell me why it's giving the error even though it installed succesfully. I know it has something to do with the shared libraries, but the installation recognized them.
SIDE NOTE: my script works fine if I don't say "use Crypt::SSLeay;" at the start, but it gives the error when I use https that it's not a supported protocol, and needs LWP::protocol::https installed. Installing that always fails.
EDIT: Thanks for your help, CJM. Apparently it was using the old version of Perl when I executed, but now I've fixed that.
It doesn't give that error anymore; however, it still says
Error GETing https://login.yahoo.com/config/login_verify2?&.src=ym: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) at lwp4 line 14
I thought Crypt::SSLeay was supposed to take care of this.
If you examine the error message, you'll notice it mentions both 5.10.1 and 5.8.0 (in the Perl library paths). This indicates that you're trying to use a module built for one version of Perl with a different version. XS-based Perl modules (i.e. ones that include C code) are not binary compatible between major releases of Perl.
It appears you installed Crypt::SSLeay using Perl 5.10.1, and are trying to use it with 5.8.0. That won't work. Use only Perl 5.10.x with that installation. If you need to use it with Perl 5.8.0 also, install another copy in a different directory.
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.