Compiling WWW::Curl on ActivePerl - perl

I'm trying (desperately) to build / install the newest version of WWW::Curl onto my activeperl box (I'll explain in a moment why I don't use the PPM)
I had to make some modifications as per the instructions found here:
http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32
I also had to change the following line:
From:
open(H_IN, "-|" "gcc", "$curl_h") and $has_cpp++;
To:
open(H_IN, "gcc $curl_h") and $has_cpp++;
I finally got perl Makefile.PL to work but now, when I run nmake, I get the following:
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE: fatal error U1077: 'C;|windows\system32\cmd.exe' : return code '0xff'
Stop.
Now, the reason I'm trying to compile this rather than using the PPM supplied by u.winnipeg is because the that PPM doesn't seem to support SSL transaction (I get "libcurl: ssl disabled") Now, if anyone can show me how to get ssl to run on this PPM, I'm more than happy to use it.
Thank you very much in advance

I presume the original was
open(H_IN, "-|", "gcc", "$curl_h")
The reason you have to change that in because noone got around to implementing feature in Windows. Change it to
open(H_IN, qq{gcc "$curl_h" |})
Use the right name and syntax for your compiler.

Well, I finally figured it out, thanks to everyone who responded. There were a bunch of things I had to change.
Using http://cpansearch.perl.org/src/SZBALINT/WWW-Curl-4.15/README.Win32 as a guide:
The open cmd as I did above worked fine. However, I did use the advice returned by ikegami, reinierpost, and mob.
Using nmake /n (as advised by socket puppet), it printed out all of the perl statements which were being executed. I took this output and placed it into a .bat file and corrected the perl syntax.
I changed all instances of
pm_to_blib({{#ARGV}
to
pm_to_blib({#ARGV}
(it is disturbing these were returned)
Then, I had to link the libcurl libraries to each line instantiating g++, which were not linked correctly. After I added these references, everything else went smoothly.
These were added:
C:\lc\curl\lib\libcurl.a C:\lc\curl\lib\libcurldll.a
Now, WWW::Curl is happily running on my system.
As for using the PPM version, it is exactly because of SSL I had to upgrade. The newest version of WWW::Curl is 4.15 the ppm version is (I believe) 3.02.

First, many people don't know that you can use ppm to install MinGW to use cpan to install modules.
Second, if the libcurl provided by your module doesn't do SSL, you can try and replace it with a suitable SSL version from the download page. This might well fail, but you might also be lucky.

Related

Problems installing "autovivification" module in Strawberry Perl

I have Strawberry Perl installed on my Windows 10 computer. I have been able to successfully install a number of CPAN modules, but I am getting stuck on the
autovivification
module.
It hangs on the make test part of the installation and I have to force it to quit. If I then try to run a program that uses no autovivification it fails with an error that it can't find the module in #INC which makes sense because it didn't install correctly.
I'm really not sure what to do next. Has anyone else had the same problem with installing this module on Strawberry Perl? What can be done about it?
Well, I'm not sure that this is really the best solution, but I think I just found a workaround for this problem. I simply skipped the make test part of the installation by opening the cpan shell, then doing: "notest install autovivification". That skipped the testing, so it wouldn't hang and it seemed to finish installing the module OK. I briefly tested the package to see if it loaded, and it seems to have, but there's a chance that something could still be wrong. I'll update this post if I encounter a problem...

Why does a packed Perl script not work on a different machine?

I have been trying to compile a script that was written in perl by someone other than myself into an executable format that can be used without having perl installed. There seems to be some sort of issue with Crypt::SSLeay packaging but I'm not sure what the error means. Here is a screenshot of the error message.
I've tried using PAR pp and cava to package, both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error seen in the screenshot. It's been the same error each time after changing compiler settings, and I'm not sure what to do at this point. If I have left anything out that may assist in answer please let me know and I will be happy to provide, coding is not my field so I am still learning and this is my first encounter with Perl.
First off, you probably do not need and should not use Crypt::SSLeay. However, both the modern Net::SSLeay and Crypt::SSLeay require OpenSSL binaries to be installed on the machine to run.
both will create executables that run just fine on the machine I'm using that has perl, but whenever I transfer it to a different computer I get the error ...
That's because the target machine does not have OpenSSL installed in the same location on which compiled the modules you are bundling.

Unable to load HMAC_SHA1 plugin

Running the Twitter Application in Perl and facing the above mentioned problem. The Perl is 5.8.8 and system is AIX with no root access.
Code
./p_t.pl
Error
Unable to load HMAC_SHA1 plugin at
/vv/mm/tt/perl5/lib/perl5/Net/Twitter/Lite.pm line 192
Hwoever
cpan Digest::HMAC_SHA1
is running fine.
O/P
Digest::HMAC_SHA1 is up to date (1.03).
and SHA1 is not running properly
cpan
force install Digest::SHA1
Running make test Can't test without successful make Running make
install Make had returned bad status, install seems impossible
Failed during this command: GAAS/Digest-SHA1-2.13.tar.gz
: make NO
I realize this is an ancient post, but it's high on google, so this advice may eventually reach someone who can use it.
I was fighting with a similar issue, and it turned out my perl distribution did not include integer.pm (part of the distro) and I fixed said bug.
To check if this, or something similar, causes problems in your case, run this script:
#!/usr/bin/env perl
use Digest::HMAC_SHA1;
And check what it fails on.

Perl cross compilation issue

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.

Why can't Perl's Class::XSAccessor find Array.so?

This is my first post and I am hoping someone can point me in the right direction. I have tried Google but am not coming up with anything; actually, there are hardly getting any hits so I assume this is going to be a pretty obscure error.
I am trying to run a perl application (squeezecenter-7.3.3) on Solaris 10 and get the following error:
"ld.so.1: perl: fatal: relocation error: file /opt/squeezecenter-7.3.3/CPAN/arch/5.10.0/i86pc-solaris/auto/Class/XSAccessor/Array/Array.so: symbol get_next_arrayindex: referenced symbol not found"
ld.so.1 is in the search path, but I can't figure out what—ld.so.1 or Array.so—is causing the error. Any help will be appreciated.
Thanks
LATE UPDATE 2009-12-04
The current version of Class::XSAccessor contains both Class::XSAccessor itself and Class::XSAccessor::Array. It does not use AutoXS.pm to generate AutoXS.h any more but ships a static copy. Therefore, the problem giving rise to the question shouldn't occur (ever) again.
While Chris Simmons' idea is a good one, this is most certainly not the problem you're having. It is most likely an incompatibility between the version of Class::XSAccessor::Array you're using and the AutoXS::Header version it was compiled with.
A practically guaranteed* fix would be to reinstall Class::XSAccessor from CPAN. It should pick up a compatible version of AutoXS::Header. Maybe you should also post on the SlimDevices/Logitech forum about this.
On a more general note, as the author of both modules in question, I'm not sure why this problem is occurring at all. The dependency on version 1.02 of AutoXS::Header is part of the most recent Class::XSAccessor::Array release. Therefore, if dependencies are met correctly, everything should be fine. It may be some peculiarity of how the SqueezeCenter folks update their bundled modules. If not, feel free to get them in touch with me.
*The one problem remaining may be that the Class::XSAccessor::Array that comes with SqueezeCenter is prefered over the one you installed from CPAN (potentially into the system). In that case, you can try to install it into your /opt/squeezecenter.../CPAN directory.
Reinstall the offending module. Run this as root:
cpan -i Class::XSAccessor::Array Class::XSAccessor
Or manually install it.