I'm working on a fresh Ubuntu vm, I've imported Mojolicious, Mango and MongoDB all through terminal (apt-gets and curls) but when I try and run any project that implements Mango - using command:
morbo project/script/project
It returns the following error:
Couldn't load application from file "project/script/project": "dumper" is not exported by the Mojo::Util module
Can't continue after import errors at /etc/perl/Mango.pm line 10
BEGIN failed--compilation aborted at /etc/perl/Mango.pm line 10.
Compilation failed in require at /home/user/project/script/../lib/project.pm line 3.
BEGIN failed--compilation aborted at /home/user/project/script/../lib/project.pm line 3.
Compilation failed in require at (eval 94) line 1.
The Mojo::Util and Mango.pm are all unedited dependencies as downloaded.
Never had any of these problems getting it to run on windows so I'm a bit lost where to start looking for a solution now.
Does anyone know what might be causing this?
Much the same as with other languages such as python or ruby, using system perl is a bad idea and will cause you headaches down the track. What will also cause you problems (much like this one) is pulling down packages "via curl" and simply unpacking to a directory. You need to install most things properly, and there are tools to manage both of these problems.
For instance, the underlying MongoDB driver module requires a C compiler to build as part of it's install process.
You may have installed that one via apt-get. But it is not recommended.
I would recommend using an "environment based" installation such as plenv or perlbrew in order to "manage" your installed perl installation, and not "mess around" with the system installed perl.
In either case, both will integrate well with the excellent cpanminus module and utility. This allows you to install packages from CPAN in a correct way, so that your application works and you avoid errors.
All options allow methods so you can install the modules locally for your application in this way. plenv may be better for you if you need "per application" separation on the same machine in this way.
Use the correct methods, and you are far less likely to run into problems.
Related
I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)
hi am trying to install perl module from cpan in my windows machine am getting below error after hitting two times yes .
Checking if your kit is complete...
Warning: the following files are missing in your kit:
README
Please inform the author.
Writing Makefile for Digest::Perl::MD5
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
Is already unwrapped into directory C:\Perl\cpan\build\Spreadsheet-ParseExcel
0.65
CPAN.pm: Going to build D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
>perl exceltoxml.pl
Can't locate Spreadsheet/ParseExcel.pm in #INC (#INC contains: C:/Perl/site/lib
C:/Perl/lib .) at exceltoxml.pl line 4.
BEGIN failed--compilation aborted at exceltoxml.pl line 4.
I have tried 5 times.
nmake' is not recognized as an internal or external command
Sinan Ünür is right. The error message is that you don't have nmake installed. This means you are attempting to compile code (probably C code) and there's no C compiler or Make program.
A while ago, I would tell people that ActiveState doesn't fully support cpan because it can't compile code. ActiveState uses it's own pre-compiled packages available via the Perl Package Manager (PPM) which can be used from the command line or from a GUI interface. If a package isn't available via the PPM and it requires compilation, you were just out of luck. I would usually recommend Strawberry Perl instead of ActivePerl for this very reason. Strawberry Perl comes with the complete MinGW environment needed for those compilable CPAN modules.
However, about a half a dozen years ago, ActiveState put together an installable PPM package for the MinGW environment. Once this is installed, ActivePerl can use CPAN.
So you have two solutions:
Install this PPM package as Sinan Ünür mentioned in his answer. Then, try Spreadsheet::ParseExcel again.
Install Strawberry Perl instead of ActiveState's Perl. Strawberry Perl seems to be more compatible with the version of Perl found on Unix/Mac/Linux systems. Then try installing the Spreadsheet::ParseExcel package.
Okay, three solutions: Install Cygwin which will give you the complete Linux Environment on your Windows machine. It can take about two hours to install, but it comes with all of the GNU utilities you've known and love, most other Unix/Linux utilities, and the BASH shell.
It's what a lot of Linux/Unix homeboys use when they get sick of that ol' C:\> prompt. Cygwin comes with the latest version of Perl and works with every single CPAN package I've tried. There are a few minor issues (Like Termcaps) where things don't quite work the way they're suppose to, but I'm generally happy with it. It even comes with X11 and allows you to run XWindow apps, and even use XWindow apps across systems -- just like a REAL operating system does!
There maybe a few instances where CPAN modules may still have issues on Windows. One has to do with archiving and unarchiving modules and the missing libz library. However, installing this MinGW package (or using Strawberry Perl or Cygwin) will solve about 95% of the cpan installation issues.
I have tried 5 times.
Computers are deterministic things. That means, unless you change the conditions under which a program runs, it will always do the same thing (except, maybe, if there is a solar flare or an EMP).
So, there is no difference between issuing the same command once versus five times. If it failed the first time, ceteris paribus, it fill fail all five times.
That said, it looks like you installed ActiveState Perl, but did not install the MinGW package which provides the gcc & dmake based build tools.
So,
C:\>ppm install MinGW
and then try to install packages.
You also have the option of building your own perl using the Community Edition of Microsoft Visual Studio 2013 tools, or any other supported compiler.
I'm trying to install some perl modules as part of the set up for Circos. I'm installing the modules using cpan in terminal, and while the initial set up seems to go well, all the modules fail during the final step of the install, when the Makefile is being written.
Here's what the error looks like:
Checking if your kit is complete...
Looks good
Writing Makefile for Font::TTF
Can't exec "make": No such file or directory at /System/Library/Perl/5.12/CPAN/Distribution.pm line 2026.
MHOSKEN/Font-TTF-1.02.tar.gz
make -- NOT OK
'YAML' not installed, will not store persistent state
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Failed during this command:
MHOSKEN/Font-TTF-1.02.tar.gz : make NO
I think the only option might be to manually install the modules instead of using cpan, but I figured it might be worth a shot to put up a question here.
It seems that /System/Library/Perl/5.12/CPAN/Distribution.pm is trying to find your system's "make" command. Since you're using Mac OS/X is "make" actually installed or do you need to add some developer tools?
To further on G. Cito's answer/question:
This old answer might do the trick for you, if you're on Mac OS/X, as the exact same error is thrown in the respective circumstances:
https://stackoverflow.com/a/6767528/2352071
I am newbie to perl cross compilation.
I'm trying to install perl from source as given in www.perl.org.
Commands followed are ./Configure, Make, Make test.
To find the path for specific installation, the CLI "perl -V" shows error as follows.
# ./perl -V
Can't locate Config.pm in #INC (#INC contains: /usr/local/lib/perl5/5.9 .).
BEGIN failed--compilation aborted.
I think i have done some mistake in path inclusions.
Please let me know the reason and solution for successfull cross compilation.
Thanks in advance.
It's probably possible to cross-compile Perl (building on Linux and targeting for BSD), but there's not much point in doing so. NetBSD is as capable as Linux of building Perl locally, and that's almost certainly what you should do.
You can build it from source, following the installation instructions, or better yet you can install a binary package, since somebody else has already done the work of building Perl from source for you.
Unless you have a very specific requirement for an old version, you should install the most recent production version, which I believe is 5.14.2.
You mentioned in a comment that when you build Perl from source on your target BSD machine, Make test had 2 failures. You had a 99.86% success rate. Surely that's good enough -- and you're not likely to do any better by cross-compiling. You might want to look into those failures and the LD_LIBRARY_PATH issue (I don't know what it should be set to for NetBSD), but those issues aren't so serious that you should give up and use a radically different approach.
I'm currently using the PAR Packer (pp) to package a couple of pl scripts such that they can be copied to a machine and "just work" without my client having to muck with CPAN.
Unfortunately, the PAR Packer doesn't work for deep dependencies. For example, a script imports CHI::Driver::File but does not explicitly import Log::Any::Adapter::Null which CHI::Driver::File requires. PAR does not pick up this dependency and running the generated script will crash with the following error message:
Can't locate Log/Any/Adapter/Null.pm in #INC (#INC contains: CODE(0x874aab8) /tmp/par-apache/cache-7b4508ab92efb43271da1629e8eb654c1572cc55/inc/lib /tmp/par-apache/cache-7b4508ab92efb43271da1629e8eb654c1572cc55/inc CODE(0x87e8f54) CODE(0x87e9194)) at (eval 215) line 3.
Compilation failed in require at CHI/Driver/File.pm line 11.
BEGIN failed--compilation aborted at CHI/Driver/File.pm line 11.
My work-around is to explicitly import "Log::Any::Adapter::Null" but there must be a better way. Perhaps this is a bug with the PAR Packer? I have installed the latest version (0.994).
Well, have you read the documentation? It gives a number of command-line options to include dependencies, and even the option to manually force modules to be included.
If you want a stand-alone script as opposed to a stand-alone binary (which is the default mode for pp), then add the -P option. I'd advise against it, though. It's the least-tested mode of operation.
Note also that PAR::Packer DOES work for deep dependencies. The subject of your question is a bit pretentious. In fact, PAR::Packer doesn't really check any dependencies itself but delegates this to Module::ScanDeps. Now, Module::ScanDeps is a heuristic approach to dependency scanning and it can be broken by ugly fuzzing with dynamic loading of dependencies. (i.e. generating module names at run time and then using them in an eval).
Indeed, if you look at the sources for Log::Any (which is used by CHI::Driver::File), you'll quickly see that it uses dynamic loading of modules. This is why the ::Adapter::Null module isn't being picked up.
Generally, we fix these issues by adding a special case to Module::ScanDeps for such modules whose author thought it'd be a good idea to defeat any sort of static analysis. Until you get a fixed version of Module::ScanDeps, you can use the -c or -x options to pp to have the dependency resolution use compilation or execution of the program instead of only relying on static analysis. The augmented Module::ScanDeps has version 0.95 and should be available from CPAN within the day.