| Subject: | upgrade to 3.44 failed in cpan |
Ran into a snag trying to upgrade XML::Twig.
From Cpan build:
Please add this information to bug reports (you can run t/zz_dump_config.t to get it)
if you are upgrading the module from a previous version, make sure you read the
Changes file for bug fixes, new features and the occasional COMPATIBILITY WARNING
t/zz_dump_config.t .................. ok
Test Summary Report
-------------------
t/test_3_40.t (Wstat: 512 Tests: 19 Failed: 0)
Non-zero exit status: 2
Parse errors: Bad plan. You planned 96 tests but ran 19.
Files=101, Tests=2837, 147 wallclock secs ( 2.93 usr 1.41 sys + 131.96 cusr 10.89 csys = 147.19 CPU)
Result: FAIL
Failed 1/101 test programs. 0/2837 subtests failed.
gmake: *** [test_dynamic] Error 255
MIROD/XML-Twig-3.44.tar.gz
/opt/csw/bin/gmake test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports MIROD/XML-Twig-3.44.tar.gz
Running make install
make test had returned bad status, won't install without force
Failed during this command:
MIROD/XML-Twig-3.44.tar.gz : make_test NO
Supporting info:
XML::Twig
-------------------------------------------------------------------------
A module for easy processing of XML
M/MI/MIROD/XML-Twig-3.44.tar.gz
/opt/csw/share/perl/csw/XML/Twig.pm
Installed: 3.22
CPAN: 3.44 Not up to date
Michel Rodriguez (MIROD)
xmltwig@gmail.com
uname -a
SunOS xxx 5.10 Generic_147440-01 sun4v sparc sun4v
perl -V
Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
Commit id: f49f26c46eb30e17edc39f23c060b8294c44115b
Platform:
osname=solaris, osvers=2.10, archname=sun4-solaris-thread-multi
uname='sunos unstable10s 5.10 generic_142909-17 sun4v sparc sunw,sparc-enterprise-t5220'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='/opt/SUNWspro/bin/cc', ccflags ='-D_REENTRANT -xO3 -m32 -xarch=sparc -I/opt/csw/bdb48/include -I/opt/csw/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV',
optimize='-xO3 -m32 -xarch=sparc',
cppflags='-D_REENTRANT -xO3 -m32 -xarch=sparc -I/opt/csw/bdb48/include -I/opt/csw/include'
ccversion='Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='/opt/SUNWspro/bin/cc', ldflags ='-m32 -xarch=sparc -L/opt/csw/lib -lperl -L/opt/csw/bdb48/lib -L/opt/csw/lib -L/usr/lib -L/usr/ccs/lib -L/lib'
libpth=/usr/lib /usr/ccs/lib /lib /opt/csw/lib
libs=-lsocket -lnsl -lgdbm -ldb-4.8 -ldl -lm -lpthread -lc -lperl
perllibs=-lsocket -lnsl -ldb-4.8 -ldl -lm -lpthread -lc -lperl
libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so.5.10.1
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /opt/csw/lib'
cccdlflags='-KPIC', lddlflags='-G -L/opt/csw/lib -L/opt/csw/bdb48/lib -L/usr/lib -L/usr/ccs/lib -L/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
PERL_USE_SAFE_PUTENV USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_REENTRANT_API USE_SITECUSTOMIZE
Built under solaris
Compiled at Jul 24 2012 13:41:27
%ENV:
PERL_RL="Perl"
@INC:
/opt/csw/lib/perl/site_perl
/opt/csw/share/perl/site_perl
/opt/csw/share/perl/site_perl
/opt/csw/lib/perl/csw
/opt/csw/share/perl/csw
/opt/csw/share/perl/csw
/opt/csw/lib/perl/5.10.1
/opt/csw/share/perl/5.10.1
.
Not sure that this is the reason it failed, but one concern I have is that Perl says it was compiled with opt/SUNWspro/bin/cc', but on my system, “which cc” -> /usr/bin/cc, and
ls -l /usr/bin/cc
lrwxrwxrwx 1 root root 21 Jan 4 2012 /usr/bin/cc -> /opt/csw/gcc4/bin/gcc*
The maintainers of OpenCSW (where I got my Perl distro from) recommend strongly that you put /opt/csw/bin (they’re stuff) first in your path for obvious reasons. But I know from experience that Perl expects any runtime executable modules it loads to be compiled with the same compiler Perl was built with, also for obvious reasons. And fairly enough, Perl won’t agree to build any binary executables if the compilers don’t match. A OpenCSW maintainer just told me via chat that they are thinking of switching everything to gcc but it will take a lot of work, and they’re all volunteers, naturally. Meanwhile, I’m in a Catch-22 I don’t know how to get out of if I want to update a module that isn’t offered by OpenCSW (or at least in the repo I want).
With many thanks for the excellent work,
-Larry
Ann Arbor, MI, USA