I'm using Perl 5.10.0 on Debian Linux (testing) and trying to install the Perl module Net::Amazon::MechanicalTurk version 1.01. When I run the module's test suite, I get errors such as the following:
t/01-ListOperations.......................Can't locate object method "new" via package "Net::Amazon::MechanicalTurk::Transport::RESTTransport" at /home/user/.cpan/build/Net-Amazon-MechanicalTurk-1.01-BO885C/blib/lib/Net/Amazon/MechanicalTurk/Transport.pm line 21.
dubious
[...]
Failed 21/33 test scripts. 12/78 subtests failed.
Files=33, Tests=78, 46 wallclock secs ( 1.50 cusr + 0.22 csys = 1.72 CPU)
Failed 21/33 test programs. 12/78 subtests failed.
Net::Amazon::MechanicalTurk::Transport::RESTTransport ISA Net::Amazon::MechanicalTurk::Transport which ISA Net::Amazon::MechanicalTurk::BaseObject which has a sub "new".
I have all of the required modules installed, as verified by the mturk_install.pl script. I've checked the issues on the module's CPAN page, but these errors are not addressed.
Has anyone had these problems and come up with any solutions? If you're successfully using this module, which version of Perl are you running?
The CPAN Testers had a similar experience.
http://www.nntp.perl.org/group/perl.cpan.testers/2009/03/msg3437850.html
You should submit a bug report to CPAN bugtracker's queue for Net::Amazon::MechanicalTurk
I've build a small patch that helps solve this problem. There's an error in the internal logic of the library which prevented all the modules from loading properly. Check out the patch and my description at http://daveviner.blogspot.com/2009/12/amazon-mechanical-turk-perl-library.html
I've applied Dave Viner's patch and two of the patches in the RT queue. There's an unauthorized release with version 1.01_01 in my CPAN directory. I'll check the CPAN Testers response for the fixes and work on an official release after that. If you're the original author, please contact me.
I know this is old post, but even in new 1.02 version it is still an issue. It is easy to fix tho - just remove "defined" from line 35 of lib/Net/Amazon/MechanicalTurk/ModuleUtil.pm and you are done. Apparently everybody at Amazon run old version of Perl.
According to CPAN Testers, the latest version of Perl which worked with Net::Amazon::MechanicalTurk was 5.8.9. I built a local copy for use with this specific module.
Related
I get a lot of errors on CpanTesters for my module EBook::MOBI::Image
(It is just some additional stuff for EBook::MOBI. Like this I keep graphics-dependencies from the main module away for those who don't need it anyways).
All tests, except those for GNU/Linux fail:
http://www.cpantesters.org/distro/E/EBook-MOBI-Image.html#EBook-MOBI-Image-0.11
Since I only have GNU/Linux and have some lack of experience in general, I ask for some help here.
The test results seem to indicate, that there is a problem with the dependency of Image::Imlib2
http://www.cpantesters.org/cpan/report/2306795e-99db-11e2-8c80-50d7c5c10595
There it says I should take care, that Image::Imlib2 is in the "Makefile.PL", but it is there as you can see:
https://metacpan.org/source/BORISD/EBook-MOBI-Image-0.11/Makefile.PL#L24
Image::Imlib2 itself does not have this issues. Tests pass all the systems:
http://www.cpantesters.org/distro/I/Image-Imlib2.html#Image-Imlib2-2.03
Can somebody give a hint here what is wrong?
The code is hosted here:
https://github.com/borisdaeppen/EBook-MOBI-Image
Thanks a lot.
When I try to install this module (on Cygwin) with the cpan command:
cpan recognizes that I need the Image::Imlib2 module (warning: prerequisite Image::Imlib2 0 not found)
cpan downloads and attempt to build Image::Imlib2
build of Image::Imlib2 fails (you must install the imlib2 library before you can install Image::Imlib2 ... Make has some problems, won't install)
cpan continues to build EBook::MOBI::Image (... Continuing, but chances to succeed are limited)
and of course, the tests for Ebook::MOBI::Image fail
The PREREQ_PM => ... directive in Makefile.PL tell cpan to make an effort to satisfy a prerequisite, but as you see, it will continue the build even if the prerequisite fails to install. The PREREQ_PM directive is good enough for most modules on CPAN, but not for modules that need an external library that cpan can't install on its own.
I think what you want in this case is for the cpan tester to bail out if you can't load the Image::Imlib2 module, and the place to do that is early in Makefile.PL.
if (!eval "require Image::Imlib2") {
print "This distribution requires Image::Imlib2!\n";
exit 0;
}
For systems that can't or won't install Image::Imlib2, bailing out of Makefile.PL will cause the tester to report a result of N/A instead of FAIL.
Thank you for taking the time reading this and hopefully help me come out with a successful solution to my problem.
I deleted this previous post as it went dead(hours without an answer), so Im hoping to revive it.
I was trying to install a perl module named Rose::DB, and after multiple approaches I finally installed it, but whenever I run my code it tells me it can't find a module named Bit::Vector, so I tried to install it.
I first did the Makefile.PL without errors.
Then, I tried doing the dmake... and It gave me A LOT of lines, most of them warnings like this:
Vector.o:Vector.c:(.text+0x11591): undefined reference to `_imp__Perl_newXS'
Vector.o:Vector.c:(.text+0x115a0): undefined reference to `_imp__Perl_get_context'
After that the last couple of lines showed this:
collect2: ld returned 1 exit status
dmake.exe: Error code 129, while making 'blib\arch\auto\Bit\Vector\Vector.dll'
Can anybody help me install the module correctly? I would really appreciate it.
PS: Here's the link to see all the lines:
http://www.sendspace.com/file/97pk32
PS: I'm using Strawberry, was using ActivePerl but gave me errors and was recommended to use Strawberry.
I had the same issue on Windows with the module Win32::UTCFileTime.
It can be due to the fact that you have both Strawberry and ActivePerl installed. And so, your perl configuration may be wrong.
If you have something like :
$ perl -V
...
cc='C:\STRAWB~1\c\bin\gcc.exe',...
...
ld='C:\STRAWB~1\c\bin\g++.exe', ldflags='... -L"C:\Perl\lib\CORE"...'
...
It means that you are trying to build perl modules with Strawberry's compiler/linker and with ActivePerl libs. It could be the reason why.
Also, an easy "hack" is to rename C:\Perl to C:\whatever temporarily.
Then, you should have :
$ perl -V
...
cc='gcc',...
...
ld='g++', ldflags='... -L"C:\strawberry\lib\CORE"...'
...
Thus, your linker will be able to find Strawberry perl CORE API functions ( _imp__Perl_*, perlguts ). It worked for me.
If there are two perl installation like Strawbery and other like Dwimperl or activeperl, renaming one which is not used, solved my problem of dmake.exe: Error code 129
I'm working on installing a perl module (not using CPAN) on a Linux machine. When I run the command:
perl Build.PL
I get the following error:
ERROR: Missing required field 'dist_abstract' for metafile
Could not get valid metadata. Error is: Invalid metadata structure.
Errors: Missing mandatory field, 'abstract' (abstract) [Validation: 1.4],
value is an undefined string (abstract) [Validation: 1.4]
at /usr/local/share/perl5/Module/Build/Base.pm line 4559
Could not create MYMETA files
I've tried Googling bits and pieces of this error but haven't found any solutions. Just looking for a clue as to what might be causing this error.
Here's a link to a zip file containing the files required to install it:
https://oncourse.iu.edu/access/content/user/brilewis/Filemanager_Public_Files/DataDownloader.zip
First at all please make sure you have package Module::Build installed.
You need ungzip few gzipped files in this package. I don't realize why author gzipped them:
gzip -d *.gz
I really don't know why author archived each install file. It looks like some mistake to me.
Than you can install all dependencies (this module requires some):
./Build installdeps
And then finally install module itself:
./Build
./Build test
./Build install
However I must warn you that this module packaged in a bit strange way and there's no guarantee it works.
The NAME section of the module does not have a - in it, e.g.,
=head1 NAME
Foo::Bar implements a Foo framework.
will fail, but if you make it
=head1 NAME
Foo::Bar - implements a Foo framework.
then it will work.
Do you have root access on your machine? Can you use the cpan utility to build and install your module. Using cpan is fairly straight forward:
$ cpan
After that, it will do a lot of configuration, simply take the default values. When it finishes, it'll come to a cpan> prompt. All you have to do there is type this:
cpan> install Module::Name
Where Module::Name is the module you're trying to install. Check the CPAN archive to get the name of your module.
If there are any dependencies, CPAN will ask if you want to download and install those. Say Yes, and CPAN will install the dependencies, then your module.
Using cpan is the best way to install third party modules you find in the CPAN archive. It takes care of all the dependencies, testing, and building for you.
Try installing through CPAN, and then see if you still have your issues.
I want to install File::Fetch, which is a core module in Perl 5.12, in my Perl 5.8.9. In general, I want to compile and install future-dated modules in my back-dated Perl because I cannot upgrade my Perl.
So I downloaded the module and also its dependencies. It's quite painful following the dependency tree but I'm more concerned about the fact that some of them are core modules. If I install these, my Perl 5.8.9 core will have patches from 5.12.
My question is how I can know whether I can safely install the future-dated modules, especially the core modules. Is there a tutorial for this purpose of testing backwardcompatability in Perl?
EDIT:
My module is dual lifed, but I cannot compile it using cpan. It said my FTPsite.yaml has a bad element. However, I followed the dependencies in the modules' META files, and I could compiled the module. Is this one of the odd bits with cpan? Thank you.
I cannot recreate the issue after I installed all those dependencies manually. But here is the error:
cpan[5]> install File::Fetch
Running install for module 'File::Fetch'
Running make for B/BI/BINGOS/File-Fetch-0.24.tar.gz
CPAN: Digest::SHA loaded ok (v5.48)
CPAN: Time::HiRes loaded ok (v1.9715)
CPAN: YAML loaded ok (v0.72)
Alert: While trying to 'parse' YAML file
'/Users/martin/.cpan/FTPstats.yml'
with 'YAML' the following error was encountered:
YAML Error: Invalid element in map
Code: YAML_LOAD_ERR_BAD_MAP_ELEMENT
Line: 3
Document: 1
at /opt/local/lib/perl5/site_perl/5.8.9/YAML.pm line 36
If the module is available separately (i.e. "dual-lifed"), as both a standalone distribution and inside core Perl, then the standalone version is safe to install on an earlier Perl, assuming its Makefile allows it. That is, if you can do cpan <Module> and it builds and tests without errors, then you are good.
The only problem is if a module is not dual-lifed, which I opined about in this question -- which is where you are likely S.O.L.
If a perl core module is also available separately, that means that it is intended to work on older perls (unless it explicitly requires some version of perl), and if it doesn't, that's a bug.
That said, 5.10 was released almost three years ago, and you are going to start seeing more and more problems using newer modules with older versions of perl.
cpan or cpanplus will handle dependencies for you.
I'm trying to compile Perl 5.10 on my FreeBSD 7.1 (BSD) server but when I run the Configure script and answer the questions I get the following error:
...POSTIX threads should be supported by FreeBSD 7.1 ... but your system is missing the shared libc_r.
Googling for the answer came up with installing gethostnamadr.c which is fine except for two things:
I don't know where to put this file and
How does this solve my problem if Configure wants to see libc_r?
To enable Perl 5.10 threads on FreeBSD 7.* all you have to do is apply the following patch using patch. You can then build perl with -Dusethreads or answer the Configure file questions to enable threading and you're good to go. I haven't done any significant testing or comparisons yet but everything compiles fine including the thread libs and all my Perl programs work fine.
--- hints/freebsd.sh 2008/10/20 04:59:30 1.1
+++ hints/freebsd.sh 2008/10/20 22:49:29
## -211,6 +211,14 ##
exit 1
;;
+ 7.*)
+ # 7.x doesn't install libc_r by default, and Configure
+ # would fail in the code following
+ #
+ # gethostbyaddr_r() appears to have been implemented in 6.x+
+ ldflags="-pthread $ldflags"
+ ;;
+
*)
if [ ! -r "$lc_r" ]; then
cat <<EOM >&4
EDIT: I forgot my reference; check here for more info: http://www.gossamer-threads.com/lists/perl/porters/232518?nohighlight=1#232518.
Contrary to Spolsky who said "perl is pretty much forgotten"... perl is very much alive.
You have not indicated which version of FreeBSD you have installed... But assuming that you have installed a min of FreeBSD 7.1 then you failed to install the threads libraries or the thread libs are not in the library path.
NOTE that libc is a general 'c' library and that libc_r is the thread-safe version of that file. Some of the 2005 google results suggest that libc_r has been deprecated.
With that in mind it is likely that you are in the middle of a "revision collision". Sadly FreeBSD does not provide the thread safe version of perl natively, however, they do package perl 5.10 and several later revisions. I found this link to be useful:
http://www.nabble.com/How---where-to-get-a-Perl-that-has-threads--td22270858.html
you might also want to try installing the p5-fork library which is included with FreeBSD
http://www.nabble.com/How---where-to-get-a-Perl-that-has-threads--td22270858.html