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.
Related
The bugzilla install is very old now (4.0.1) and although it would be best, upgrading is a real pain as I suck at Perl related stuff. It has worked with no issue for many years and stopped in December. On checking the serverhost changed to Perl 5.16.3. Originally it was 5.8.8 and even after 15.10 it worked fine.
The issue I get is very similar to this issue - Bugzilla: bugs are not showing up (show up in DB and everything seems to be fine)
But it is not a template or character problem (the site ran fine with no changes) that I can see and happened the same week the host updated Perl , so I am 99% sure it is Perl related. I am assuming the issue is with either buglist.cgi itself or search pm. Any time I browse or search the Product, component, resolution etc shows "ARRAY and a number. e.g. Product: ARRAY(0x30090f0) Component: ARRAY(0x3993420) Resolution: ARRAY(0x3993378).
The bugzilla is only accessible internally (but hosted by a third-party, so no admin) it only allows user accounts access to search and browse so I cannot demo the issue. Is there a known depreciated Perl command?
Would love to fix but may have to install a new version and import DB, last time it took a few weeks to get running hence looking to avoid that for now.
I had the exact same issue. After digging a little figured this is an issue with the Perl version. In Search.pm, $params->param("field$chart-$row-$col", shift(#$ref)); this line is causing the issue. With 5.8.8 its returning Array object, whereas with 5.16.3 it is returning SCALAR.
My option is to install 5.8.8 and re-install the compatible modules. Or, is there any quick workaround for this?
Update:
Going through the docs, figured that 4.0.10 version of bugzilla has added support for Perl 5.16. Copied the CGI.pm from that and tested.. bugzilla is working. This is a bad hack. But, at least now I know that upgrading to 4.0.10 is another viable solution instead of upgrading Perl.
I have installed Net-SMTP-SSL (/usr/bin/perl install-module.pl Net::SMTP::SSL) since I'd like to configure Bugzilla email with Gmail. I did't got any error. However, when I run './checksetup.pl --check-modules', I still get the result:
Checking for Net-SMTP-SSL (v1.01) not found
I also try to re-install it and I still get the same output. Here is my system information:
Ubuntu 12.04
Bugzilla 4.4.6
After having the same problem with Bugzilla recently, I ran across this rejected bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=897355
It mentions that there are some dependencies that Bugzilla isn't installing, but doesn't say which ones. So I just ran cpan and issued the upgrade command from the cpan console to upgrade all packages. This went though and installed a few dependencies from various packages that it said were missing. I didn't see which ones were related to the SMTP SSL package since it was installing stuff several levels deep in dependencies, but after running that and then running checksetup.pl in Bugzilla, the problem seemed to be fixed. Warning: It did take quite a while to upgrade all packages, though.
That fixes the issue with Bugzilla not detecting properly, but unfortunately it seems there's a bug in Net::SMTP::SSL conflicting with one of it's own dependencies. You'll get an error something like "Not a GLOB reference" if you try to run the package directly. You can see it by running this after updating all of the packages:
perl -MNet::SMTP::SSL -wE 'say $Net::SMTP::SSL::VERSION'
If you get a version number returned then it's working, but I get an error and have seen other posts about it, too. I haven't been able to fix this problem yet, but there's probably some combination of the SSL package and various versions of it's dependencies that actually works, just not the latest of each. Otherwise, I would think there would be a known issue in Bugzilla release notes as they would have run across it during testing.
I haven't had time to do it and haven't seen that anyone else has either including the package maintainer, but I suppose you could find all of the dependencies for Net::SMTP:SSL and then one by one update the packages using something like:
cpan upgrade Net::SMTP::SSL
Then replace Net::SMTP::SSL with each of it's dependencies one at a time and test using the perl command above. When it breaks, you'll know which package is conflicting. You can then roll that package back to an earlier version and update all other dependencies and hopefully it will fix the issue. It's definitely possible that no combination will work, though, and if that's the case, I'll be a little disappointed in Bugzilla's testing process.
You can find dependencies using various methods, but CPAN has one. Here's a link to an article about how to create a perl script to use it: https://metacpan.org/pod/CPAN::FindDependencies
Anyway, this may not solve your problem, but I hope it helps in tracking down the issue, and know that you are not alone. If you do find out anything, please post it here. I will do the same if I have more time to work on it later.
The question How do I upgrade strawberry perl without wiping \perl\site\lib\ and \perl\site\bin\? was asked in 2011 and it appears Strawberry did throw out any CPAN installs the user did whenever we upgraded to a newer version. Is this still the case? I found a comment from Adam Kennedy which seems related but I'm not sure whether the change was actually made and what its implications are.
Since Strawberry Perl is said to be "100% Open Source" I tried looking for a development site, a place where we could get more details and look at discussions, but I couldn't find any, the strawberryperl.com site is strangely devoid of any information in this regard. Even its Wikipedia page is (slightly) more informative. (Edit: I found http://code.google.com/p/strawberry-perl/ which could be a neat central portal of links, also http://search.cpan.org/~kmx/Perl-Dist-Strawberry-3.012/script/perldist_strawberry is quite informative.)
Also, in case Strawberry still does this, how can I make a local backup copy of the modules? I don't want to have to use CPAN's autobundle and redownload everything from scratch unnecessarily.
Update for future reference: from the comments I gather that since the content in site/lib and site/bin are currently build-dependent in Strawberry Perl, it's necessary to wipe them out and start afresh when installing a new version. This necessity might go away if Strawberry introduces a separate arch-directory to store architecture dependent stuff.
I would just rename C:\strawberry to C:\strawberry-old before installing the new version. Chances are you could just copy modules from the old installation to the new one (not forgetting to look for bits in the "auto" directories). That said, I would probably just reinstall everything from CPAN anyway to get the latest versions. It helps if you have a .bat file that automates this for your favourite additions.
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.
I'm having trouble installing Template module with Strawberry Perl.
cpan Template
yields the following:
Writing Makefile for AppConfig
C:strawberryperlbinperl.exe: not found
dmake.EXE: Error code 255, while making 'blib\lib\.exists'`
I haven't been able to understand either
how to affect the path so dmake will work correctly
why the path (which is correct) does not have any \ in it.
If you've been using MKS, you not only need to be sure you've removed it from your PATH, but you also need to ensure you don't have SHELL set to point to the MKS sh.exe.
I removed it from my PATH, and continued to struggle with this for a couple of more days until I realized dmake was invoking the wrong shell.
Hope this helps someone else down the road.
The answer was I needed to uninstall (or at least remove from my path) the MKSTookit (basically a unix shell environment for Windows like Cygwin.) Not exactly sure why this fixed the problem - but it has cleared things up and I am able to install via CPAN.
Thanks for everybody's answers and comments.
You've probably been bit by escaping. Somewhere something is configured with the path C:\strawberryperl\bin\perl.exe, but those slashes need to be escaped to:
C:\\strawberryperl\\bin\\perl.exe
Not knowing more about how you installed your perl, I can't tell you where this bad config value is likely to be found.