I get the following error while trying to build code on a 64bit machine.
Can't load '/e/pkgs/linux/intel/perl/5.8.0/lib/site_perl/5.8.0/i686-linux/auto/XML/LibXML/Common/Common.so'
for module XML::LibXML::Common: libxml2.so.2: wrong ELF class: ELFCLASS64
at /e/pkgs/linux/intel/perl/5.8.0/lib/5.8.0/i686-linux/DynaLoader.pm line 229.
at /e/pkgs/linux/intel/perl/5.8.0/lib/site_perl/5.8.0/i686-linux/XML/LibXML.pm line 11
The perl is 32bit, but I have both 32 and 64bit versions of libxml2.so.2 on my machine. Is it trying to use the 64bit version of libxml2?
The library you are failing to load is one that supports the Perl XML::LibXML::Common module, not the libxml2 library. Most pure Perl modules are pretty portable across different versions of perl and even different platforms, but the binary files that sometimes support those modules are not, and you will get errors like this when you try to use a library that was built for one platform/version on another platform/version.
You will want to reinstall the XML::LibXML Perl distribution for your current system. Depending on how the wrong binaries got installed for your system, you may need to do this for several other distributions, too.
But before you do that, you might want to upgrade your version of Perl. Perl 5.8 is ancient, and Perl 5.8.0 is old even by the standards of Perl 5.8.
(running cpan XML::LibXML should reinstall that distribution for you)
Related
I have installed Debian 10 in order to migrate a web server from one machine to this Debian 10 machine. The web server built on apache2 needs mod_perl. The module was not found on the new machine, so I installed perl5.28 (and mod_perl.so has been added). But now it seems there is a mismatch between a previous perl version (5.20) and the latest one (5.28). I use the perl binary correspondint to v5.28, #INC contains directories related to v5.28 (according to "env -i perl -V"). But when I try to start the apache2 server, I get this error: "apache2: Perl lib version (5.28.1) doesn't match executable '/usr/sbin/apache2' version (5.20.2)". Can anyone help? Thanks a ton in advance.
When you built apache with mod_perl, you used v5.20, but it seems that's not around anymore. Different versions of Perl are not guaranteed (or even attempt to be) binary compatible. Between Perl versions, you'll likely have to re-compile all XS modules, too.
You need to recompile apache with the Perl that you want to use, or install the Perl that apache wants to use. This time you may want to statically compile mod_perl into apache.
This problem isn't specific to Perl, though. Many software libraries will complain similarly when you replace the library they compiled against.
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 compile the perl DBI package on solaris 10 say SERVER1 with say perl 5.8.10 installed on it and create DBI.
Now I copy the above DBI.so and the DBI.pm files to another solaris SERVER2 machine with the same hardware and the same version of perl.
Can I be sure that the DBI package will run smoothly and I will not get any run-time errors in future ?
Please note that I dont have the flexibilty to install a C compiler SERVER2.
Hardware does not matter so much as you think, the operating system abstracts this away nicely. For binary compatibility, the minor version must match, so the other Perl must also be from the 5.8 series. (By the way, 5.8.9 was the last one, 5.8.10 does not exist.)
As you're talking about a dynamic library, the integration on the C level is much more important. Are the libraries referenced from the DBI.so compatible (e.g. libc.so has the same version on both machines)? Check with the ldd command.
In case of mismatches, you will not get run-time errors, but very obvious crashes at compile time when perl attempt to load DBI.
The answer is the same as in this question: How can I install Perl modules on a restricted server? -- install your modules and libraries on a system with the same architecture (using a special installation directory), then copy the modules over to your restricted system.
You'll need a C compiler somewhere (unless you can find pre-compiled binaries of the .so or .dll files you need), but it doesn't have to be on the intended target.
I'd like to install a Perl module (in this case, FindBin), but since it is included in the Perl 5.10.1 distribution, cpan wants to install Perl 5.10 for me. Is there a way of installing just the module via cpan?
The only option that I can see is installing directly from source, which seems a bit crude as there is no separate package (for example, Makefile.PL, etc.), just the bare .pm file.
Since this is a small module that only has the one file, it's doable in this case, but what if I wanted to install a much larger package?
EDIT: This is somewhat aside from the original question, but speaks to the general issue of modules being packaged up with Perl distributions: I discovered that the "standalone" FindBin (version 1.49) had a syntactic error, so I retrieved version 1.50 out of the Perl 5.10.1 distribution... However since the module is now listed on CPAN as part of Perl 5.10, I am unable to find the CHANGES file describing what was changed/fixed in this delta. Is it reasonable that I should have to go into the developer repository to pull out this information?)
EDIT 2. Okay, here's a better example. On Perl 5.8.8 I have version 1.04 of Carp. However, I see that Perl 5.10.1 comes packaged with version 1.11. Is there a way of getting CPAN to install the latest version of Carp for me without dragging in all of Perl 5.10.1? I can't even find a link to the Carp module on CPAN except to the perl 5.10.1 installation.
> corelist FindBin
FindBin was first released with perl 5.00307
Which version of Perl do you use that does not include FindBin? If you use at least Perl 5.6.0 (all versions before are considered deprecated), you have no need to install FindBin. If you have anything older, I suggest an upgrade to 5.6.2/5.8.9/5.10.1.
Kurila is not a "standalone" FindBin, it's a dialect of Perl. FindBin is not a dual life and is released only bundled with Perl. You can consider releasing FindBin to CPAN as standalone distribution - it is easy if you used ExtUtils::MakeMaker in past.
Latest useful change of FindBin was on 2007-04-28, related to VMS. Latest useful non-VMS change was on 2006-10-25.
Things you can try include
Dropping FindBin.pm into the same directory as your executable and using use FindBin
Dropping FindBin.pm into your Perl library directory
Using the source code of the module in your script
I am looking at embedding perl 5.10 in a large C++ application compiled with VC++ 6.0. This leads to two questions.
1) Is it a bad idea to simply use Strawberry Perl as a dependency rather than compile my own perl with VC++ 6.0? Would Strawberry even work given the compiler mismatch? I presume Strawberry is compiled with mingw. I would much rather not have to keep my own custom perl build around.
2) If I went the Strawberry route, would something like Inline::C work in the embedded application? You'd have VC++ 6.0 code calling mingw compiled Strawberry in turn calling user mingw compiled code. Inline::C would be an awesome capability for what I'm trying to achieve with the embedded perl interpreter.
Given the uncertainty involved, I would recommend compiling Perl using MSVC instead of experimenting with Strawberry Perl for this application. There are instructions in perlwin32 and a related discussion on Perl Monks to guide you.
As a former release manager for Strawberry Perl, I can tell you it's not terribly difficult to do if you're comfortable with a compiler already.
-- xdg
Activestate perl is compiled with VC++ 6.0. It can use VC++ 6.0 or MinGW to compile modules since they link to the same C runtime library, msvcrt.dll. It would be preferable to use MinGW because VC++ 6.0 is neither free nor readily available (unless you can be sure that it is installed on the target machine.) You can PPM install Mingw now, and compile modules from CPAN. A large number of modules compile without trouble. You may have to configure CPAN with:
o conf yaml_module '' (Two single quotes, nothing between)
o conf commit
Inline::C works.