Since about 2 days we have problems running our tests with appveyor on windows systems.
We get the error message:
(CustomBuild target) ->
CUSTOMBUILD : error : Problems running bibtex. Verify that the command 'perl --version' works from the command line. Exit code: 2
We installed the bibtex.
It concerns (at least) the "VSVERSION=15 2017" and VSVERSION=14 2015" for 32 and 64 bit
Did anything change on the Windows machines regarding perl?
At the end the problem was not a missing perl executable but an executable (bibtex) called from the used perl script.
The bibtex executable was not provided by MiKTeX anymore resulting in this, misleading, resulting error.
The MiKTeX problem has been solved by means of: https://github.com/MiKTeX/miktex/issues/443 by declaring the package miktex-misc an essential package (again).
Related
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
I've seen two threads similar to my question, neither with an answer that helps me.
I have been given a new laptop running Windows 7 Enterprise SP1 64-bit, on which I've installed Active Perl 5 'version 20, subversion 2 (v5.20.2) built for MSWin32-x64-multi-thread' and Microsoft Visual Studio Express 2015.
Both 'C:\perl64' and 'c:\program files (32)\Microsoft Visual Studio 14.0\VC\bin' are in my system path [without the single quotes, of course] and if I run nmake on the command line without any arguments and without a makefile in the pwd I get back the following message, definitely indicating that nmake can be found:
Microsoft (R) Program Maintenance Utility Version 14.00.23026.0
Copyright (C) Microsoft Corporation. All rights reserved.
NMAKE : fatal error U1064: MAKEFILE not found and no target specified
Stop.
So far, so good. Now, when I run Makefile.PL to start installing a new package, I get the following message:
It looks like you don't have either nmake.exe or dmake.exe on your
PATH, so you will not be able to execute the commands from a Makefile.
You can install dmake.exe with the Perl Package Manager by running:
ppm install dmake
Checking if your kit is complete... Looks good Generating a
dmake-style Makefile
What I don't understand and would like to resolve is why Perl does not see the nmake in my PATH environment? I've installed this same package previously on a number of different machines in the past - the only real variation in any of these has been in the version number of Perl and MSVS release and the bit-version of Perl [in almost all cases I've been working 32-bit instead of 64], but I don't see why either of these would make a difference to Perl not recognizing the MSVS bin directory in my %PATH%
Installing dmake or minGW is not a solution for me: I've already done both and get a series of errors I've never experienced before with this package, so I'd really like to find a solution that would allow me to use nmake - if I still get errors afterwards, I'll work those out when I get to them.
Thanks
Edit C:\Perl64\lib\ExtUtils\MakeMaker.pm and add "require Module::Build;" before "require Exporter;" line. The top should now look something like this:
# $Id$
package ExtUtils::MakeMaker;
use strict;
BEGIN {require 5.006;}
require Module::Build; # THIS IS ADDED
require Exporter;
use ExtUtils::MakeMaker::Config;
use ExtUtils::MakeMaker::version; # ensure we always have our fake version.pm
use Carp;
use File::Path;
That fixed it for me.
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 learnt basisc about Scheme and want to try Guile.
When copied this sample here the first one and run as a script, an Error occured,
$ guile copy.scm
ERROR: no code for module (gnome-2)
My laptop runs Fedora 16 x86_64, with yum install guile*
How to deal with Guile's modules?
May be you need guile-gnome-plataform-devel?
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.