I am trying to build an operating system using Yocto and the recipe keeps flaking out on a mismatch in Perl libs:
MiscXS.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdb80080)
When it is building qemu.
Any idea which what this actually means? Do I need to "downgrade" the perl libs on the build host?
The build of Perl that is attempting to load the module is different than the build of Perl that installed (compiled) it.
perldiag:
(P) A dynamic loading library .so or .dll was being loaded into the
process that was built against a different build of perl than the
said library was compiled against. Reinstalling the XS module will
likely fix this error.
Related
I'm trying to install Math::Pari module but getting error.
I'm installing on Windows Server 2012R2, I've Strawberry perl v5.18.4.1 32-bit currently installed on it.
Actually Math::Pari is dependency for Net::SSH::W32Perl and I want to install that module.
Following is the error log. Please Give me step by step installation procedure.
cpanm (App::cpanminus) 1.7039 on perl 5.018004 built for MSWin32-x64-multi-thread
Work directory is C:\Users\script/.cpanm/work/1438929213.2276
You have make C:\strawberry\c\bin\dmake.exe
You have LWP 6.08
Falling back to Archive::Tar 2.02
Searching Math::Pari () on cpanmetadb ...
--> Working on Math::Pari
Fetching http://www.cpan.org/authors/id/I/IL/ILYAZ/modules/Math-Pari-2.010808.zip
-> OK
Unpacking Math-Pari-2.010808.zip
Entering Math-Pari-2.010808/
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (6.98)
Configuring Math-Pari-2.010808
Running Makefile.PL
Did not find GP/PARI build directory around.
Apparently, you are running a 64-bit Perl built with MicroSoft's compilers.
GP/PARI (at least the versions I know how to work with, 2.1.* and 2.3.*)
cannot be built in this environment. I won't auto-download GP/PARI.
If you believe that this message is printed erroneously, please report
(see files README and INSTALL), and put force_download on the command line:
perl Makefile.PL force_download
One can rerun Makefile.PL after fetching GP/PARI archive (e.g., pari-2.1.7.tgz,
or pari-2.3.4.tar.gz) manually to the current directory, or a (grand)parent
directory of the current directory.
[Keep in mind that the numbers "inside version" of Math::Pari module
correspond to the last versions of GP/PARI it was tested with (additionally,
2.0108* works best with the last 2.1.* version, 2.1.7).
As an alternative to having archive in CWD or its (grand)parent, specify
pari_tgz=PATH_TO_TAR_GZ
option to Makefile.PL.
There is no need to extract the archive, or build GP/PARI; but if you
have it extracted [and patched, if needed], you may specify
paridir=PATH_TO_DIST_DIR
option to Makefile.PL instead of `pari_tgz'. However, in this case
the files WON'T be auto-patched.
As a last-resort solution, there is also a possibility to use an already
compiled PARI library. See the documentation in README and INSTALL files.]
Could not find GP/PARI build directory, please run Makefile.PL
with paridir=/directory option.
-> N/A
-> FAIL Configure failed for Math-Pari-2.010808. See C:\Users\script\.cpanm\work\1438929213.2276\build.log for details.
I thought I'd add a note for anyone coming here as a result of a Google search after their own Math::Pari install fails under Strawberry Perl.
Here is what worked for me (Strawberry 5.22):
A. from the cpan shell, tried to install Math::Pari. this failed
B. Downloaded pari-2.1.7 and placed the extracted folder pari-2.1.7 in the cpan build folder that was created in (0). This is found, by default, in C:\Strawberry\cpan\build
C.perl Makefile.PL Configure machine=none
D. dmake
E. dmake install
It basically means that 64 bit versions of perl are not supported. It also means that if you're sure that you're running a 32 bit version incorrectly detected as 64 bit, you can try opening a command line and then doing
cd C:\Users\script\.cpanm\work\1438929213.2276\
perl Makefile.PL force_download
install IO::Pty cpan
Tty.xs:54:23: sys/ioctl.h: No such file or directory
Tty.xs: In function `make_safe_fd':
Tty.xs:225: error: `F_DUPFD' undeclared (first use in this function)
Tty.xs:225: error: (Each undeclared identifier is reported only once
Tty.xs:225: error: for each function it appears in.)
dmake.exe: Error code 129, while making 'Tty.o'
TODDR/IO-Tty-1.10.tar.gz
C:\Perl\site\bin\dmake.exe -- NOT OK
no SFTP module is getting install.
First, that distribution is called IO::Tty (which contains an IO::Pty module).
You seem to be missing some header files for a C library your module is linking to. You would have to install the headers beforehand. However… ioctl is Unix-specific and a part of the operating system. It is also notoriously unportable.
I could not find any reports of a IO::Tty install working on Windows, so it seems you can't use that module on Windows (without a Cygwin environment). As it happens this is also what the IO::Tty documentation says:
Windows is now supported, but ONLY under the Cygwin environment, see http://sources.redhat.com/cygwin/.
My ultimate goal is to run a twiki website for my research group.
I have space on RedHat server that is running Apache, etc., but upon which I do not have root access. Since I cannot install perl modules with the current permissions, I've decided to manually install a local version of perl. Got that working no problem. The following modules are required to get twiki to work:
FreezeThaw - http://search.cpan.org/~ilyaz/FreezeThaw
CGI::Session - http://search.cpan.org/~markstos/CGI-Session
Error - http://search.cpan.org/~shlomif/Error
GD - http://search.cpan.org/~lds/GD
HTML::Tree - http://search.cpan.org/~petek/HTML-Tree
Time-modules - http://search.cpan.org/~muir/Time-modules
I have installed FreezeThaw, CGI, Error, and it fails on GD with the following error:
UNRECOVERABLE ERROR Could not find gdlib-config in the search path.
Please install libgd 2.0.28 or higher. If you want to try to
compile anyway, please rerun this script with the option --ignore_missing_gd.
In searching for how to get around this newest obstacle, I found a previous SO question: How to install GD library with Strawberry Perl asked about installing this and the top answer suggested manually compiling gdlib. You'll note, however, that that link is broken. The base site: http://www.libgd.org/ is basically down saying to go to the project's bitbucket page.
So I got the tarball from that page and am trying to install it. The following problems occur when I follow the instructions included. README.TXT says: "If the sources have been fetched from CVS, run bootstrap.sh [options]."
Running bootstrap.sh yields:
configure.ac:64: warning: macro `AM_ICONV' not found in library
configure.ac:10: required directory ./config does not exist cp: cannot
create regular file `config/config.guess': No such file or directory
configure.ac:11: installing `config/config.guess' configure.ac:11:
error while copying cp: cannot create regular file
`config/config.sub': No such file or directory configure.ac:11:
installing `config/config.sub' configure.ac:11: error while
copying cp: cannot create regular file `config/install-sh': No such
file or directory configure.ac:28: installing `config/install-sh'
configure.ac:28: error while copying cp: cannot create regular
file `config/missing': No such file or directory configure.ac:28:
installing `config/missing' configure.ac:28: error while copying
configure.ac:577: required file `config/Makefile.in' not found
configure.ac:577: required file `config/gdlib-config.in' not found
configure.ac:577: required file `test/Makefile.in' not found
Makefile.am:14: Libtool library used but `LIBTOOL' is undefined
Makefile.am:14: The usual way to define `LIBTOOL' is to add
AC_PROG_LIBTOOL' Makefile.am:14: to configure.ac' and run
aclocal' and autoconf' again. Makefile.am:14: If `AC_PROG_LIBTOOL'
is in `configure.ac', make sure Makefile.am:14: its definition is in
aclocal's search path. cp: cannot create regular file
`config/depcomp': No such file or directory Makefile.am: installing
`config/depcomp' Makefile.am: error while copying Failed
And it says I should also install the following 3rd party libraries:
zlib, available from http://www.gzip.org/zlib/
Data compression library
libpng, available from http://www.libpng.org/pub/png/
Portable Network Graphics library; requires zlib
FreeType 2.x, available from http://www.freetype.org/
Free, high-quality, and portable font engine
JPEG library, available from http://www.ijg.org/
Portable JPEG compression/decompression library
XPM, available from http://koala.ilog.fr/lehors/xpm.html
X Pixmap library
Which I am ignoring for now.
Switching to the generic instructions it says follow the advice in the INSTALL file; which says: "cd to the directory containing the package's source code and type ./configure to configure the package for your system." Which flat does not work: I've cd'ed into every directory of the tarball and running that command does nothing.
So, trying to install twiki required me to install perl, which required me to install the perl modules: FreezeThaw, CGI, Error, HTML, Time-modules, and GD -- which itself required me to install gdlib -- which further suggested I install zlib, libpng, FreeType 2.x, JPEG library, and XPM. And of course, I'm stuck at the installing gdlib stage.
My question is: what other process can possibly demean humanity to such a level? I cannot fathom the depths of cruelty that lay ahead of me as I dive ever deeper into this misery onion. Should I just end it all? Can meaning be brought from this madness? Will the sun come up tomorrow, and if so, does it even matter?
But seriously, any suggestions on what to do differently/better would be much appreciated -- I can't remember what a child's laughter sounds like anymore.
Install the package gd-devel, it contains /usr/bin/gdlib-config.
This should work:
sudo apt-get -y install libgd2-xpm-dev build-essential
I am trying to get WWW::Mechanize to login to Yahoo using https; however, it requires the use of Crypt::SSLeay for sending over https.
Crypt::SSLeay installed succesfully, and openssl was already installed on the system.
However, it gives the error upon loading:
Can't load '/home/gen19/perl5/lib/perl5/lib/site_perl/5.10.1/i686-linux//auto/Crypt/SSLeay/SSLeay.so' for module Crypt::SSLeay: /home/gen19/perl5/lib/perl5/lib/site_perl/5.10.1/i686-linux//auto/Crypt/SSLeay/SSLeay.so: undefined symbol: PL_sv_undef at /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
at /home/gen19/lwp4 line 15
Compilation failed in require at /home/gen19/lwp4 line 15.
BEGIN failed--compilation aborted at /home/gen19/lwp4 line 15.
The installation of Crypt::SSLeay was successful, and could recognize the installation of openssl (here):
perl Makefile.PL
=======================================================
Only one OpenSSL installation found at /usr
Consider running 'perl Makefile.PL --default' the next
time Crypt::SSLeay is upgraded to select this directory
automatically thereby avoiding the following prompt.
=======================================================
Which SSL install path do you want to use? [/usr] /home/gen19/ssldir
BUILD INFORMATION
================================================
ssl library: OpenSSL 0.9.8 in /home/gen19/ssldir
ssl header: openssl/ssl.h
libraries: -L/home/gen19/ssldir/lib -lssl -lcrypto -lgcc
include dir: -I/home/gen19/ssldir/include/openssl -I/usr/kerberos/include
================================================
Note (probably harmless): No library found for -lgcc
Writing Makefile for Crypt::SSLeay
The test suite can attempt to connect to public servers
to ensure that the code is working properly. If you are
behind a strict firewall or have no network connectivity,
these tests may fail (through no fault of the code).
Do you want to run the live tests (y/N) ? [N]
NOTE: recently installed Perl v5.10.1 using App::perlbrew, due to LWP::UserAgent's needing it. I installed Crypt::SSLeay using my new version of Perl.
I don't have root priveldiges, as I am doing this on a remote server at school. Please tell me why it's giving the error even though it installed succesfully. I know it has something to do with the shared libraries, but the installation recognized them.
SIDE NOTE: my script works fine if I don't say "use Crypt::SSLeay;" at the start, but it gives the error when I use https that it's not a supported protocol, and needs LWP::protocol::https installed. Installing that always fails.
EDIT: Thanks for your help, CJM. Apparently it was using the old version of Perl when I executed, but now I've fixed that.
It doesn't give that error anymore; however, it still says
Error GETing https://login.yahoo.com/config/login_verify2?&.src=ym: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) at lwp4 line 14
I thought Crypt::SSLeay was supposed to take care of this.
If you examine the error message, you'll notice it mentions both 5.10.1 and 5.8.0 (in the Perl library paths). This indicates that you're trying to use a module built for one version of Perl with a different version. XS-based Perl modules (i.e. ones that include C code) are not binary compatible between major releases of Perl.
It appears you installed Crypt::SSLeay using Perl 5.10.1, and are trying to use it with 5.8.0. That won't work. Use only Perl 5.10.x with that installation. If you need to use it with Perl 5.8.0 also, install another copy in a different directory.
In Perl, what does this error mean?
Unresolved symbol: Perl_Gthr_key_ptr
I am getting this error while converting a Perl file to binary using perl2exe on a HP-UX PA-RISC machine.
/usr/lib/dld.sl: Unresolved symbol: Perl_Gthr_key_ptr (code) from /tmp/p2xtmp-9979/Cwd.sl IOT trap (core dumped)
Off the top of my head it looks like a non-threaded perl trying to load modules compiled for a threaded perl.
EDIT: to clarify, you can compile Perl with support for threads (threaded perl) or without support for threads (non-threaded perl). If the module was built to be used with threads and is loaded by a perl without support for threads it usually produces the above error.
To check for thread support in perl, just search for the "thread" string in the output of perl -V:
perl -V | grep thread
A Perl module is being loaded which is not binary-compatible with your base Perl installation. This can result from, among other circumstances, having previously installed modules with the CPAN shell and then using your OS package manager to upgrade Perl underneath it. This situation can be resolved by
$ cpan -r
which will find all your CPAN modules with a binary component, and recompile those binary components against your current installation of Perl.