You are viewing a plain text version of this content. The canonical link for it is here.
Posted to p-dev@xerces.apache.org by David Starks-Browning <st...@ebi.ac.uk> on 2001/10/10 13:56:11 UTC
problems with 1.5.7 on dec_osf1
On 7 Oct 01, Jason E. Stewart writes:
> Hey All,
>
> I'm pleased to announce the new release of XML::Xerces. Because of big
> improvements in SWIG, I've been able to really simplify how the code
> is generated, and that should help porting to different
> architectures.
>
> One big issue that has made porting dificult is my bad choice of using
> the standard C++ iostream cerr in many of the error reporters. This
> created all sorts of problems between gcc's implementation and other
> compiler vendor's implementations. Instead I now use the Perl's
> builtin croak() method. So I'm hoping this reducing a lot of
> relocation and linking problems that people have reported.
Jason,
I have a couple of things to report, which are separate but related.
Apologies for the length of this message. I'm completely ignorant of
both MakeMaker and C++ (what I'm writing about), but here goes...
This is Compaq Tru64 UNIX V5.0A (Rev. 1094), building
XML-Xerces-1.5.7 for perl5.00503, against xerces-c-src_2001-10-05.
Both perl and xerces-c were built with gcc-2.95.3.
Before editing hints/dec_osf1.pl, here is the output of "perl
Makefile.PL":
> Using XERCES_LIB = /sw/common/src/xerces-c_2001-10-05/alpha-osf1/lib
> Using XERCES_INCLUDE = /sw/common/src/xerces-c_2001-10-05/alpha-osf1/include
> Checking to see if libxerces is in your library path...Use of uninitialized value at (eval 24) line 98.
> Use of uninitialized value at (eval 36) line 74.
> Use of uninitialized value at (eval 36) line 75.
> Use of uninitialized value at (eval 36) line 76.
> Use of uninitialized value at (eval 36) line 89.
> Use of uninitialized value at (eval 67) line 14.
> Use of uninitialized value at (eval 67) line 15.
> Use of uninitialized value at (eval 67) line 16.
> Use of uninitialized value at (eval 67) line 17.
> Use of uninitialized value at (eval 67) line 19.
> Use of uninitialized value at (eval 67) line 20.
> Use of uninitialized value at (eval 67) line 21.
> Use of uninitialized value at (eval 67) line 22.
> Use of uninitialized value at (eval 67) line 34.
> Use of uninitialized value at (eval 67) line 43.
> Success!!
> Using Xerces-C version: 1.5.1
> Checking if your kit is complete...
> Looks good
> Processing hints file hints/dec_osf.pl
> 'CC' is not a known MakeMaker parameter name.
> 'CCFLAGS' is not a known MakeMaker parameter name.
> 'LD' is not a known MakeMaker parameter name.
> 'PREREQ_PM' is not a known MakeMaker parameter name.
> Warning: Guessing NAME [alpha-osf1] from current directory name.
> Writing Makefile for XML::Xerces::DOMParse
> Writing Makefile for Handler
> Checking if your kit is complete...
> Looks good
> Processing hints file hints/dec_osf.pl
> Writing Makefile for XML::Xerces::DOMParse
> Writing Makefile for XML::Xerces
Notice how hints/dec_osf.pl is processed twice, but seems not to make
sense of it the first time. In my case, since perl was built with gcc
but hints/dec_osf1.pl sepecifies cxx, I find that Handler/Makefile
uses gcc, but Xerces.C is compiled with cxx. Does that make sense? I
have no idea how to read Makefile.PL files, sorry!
After commenting out the cxx definitions in hints/dec_osf1.pl (since
gcc should be able to handle C++ code), I get the following error in
"make":
> gcc -c -I. -IHandler -I/sw/common/src/xerces-c_2001-10-05/alpha-osf1/include -D_REENTRANT -DHAS_BOOL -O3 -DVERSION=\"1.5.7\" -DXS_VERSION=\"1.5.7\" -fpic -I/sw/common/share/perl/5.00503/alpha-osf1/CORE Xerces.C
> Xerces.C: In function `struct swig_type_info * SWIG_TypeCheck(SV *, swig_type_info *)':
> Xerces.C:175: passing `const char *' as argument 2 of `Perl_sv_derived_from(SV *, char *)' discards qualifiers
> make: *** [Xerces.o] Error 1
Is that a problem with my configuration or with Xerces.C?
Thanks for your help.
Regards,
David
-------------------------------------------------------------------
David Starks-Browning | starksb@ebi.ac.uk
EMBL Outstation -- |
The European Bioinformatics Institute |
Wellcome Trust Genome Campus | tel: +44 (1223) 494 616
Hinxton, Cambridge, CB10 1SD, UK | fax: +44 (1223) 494 468
-------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: problems with 1.5.7 on dec_osf1
Posted by David Starks-Browning <st...@ebi.ac.uk>.
On 10 Oct 01, Jason E. Stewart writes:
> All the rest seem to be associated with the code that I changed, which
> is problematic. Presumably, there is something wrong with how I
> implemented the usage of croak() for early versions of Perl.
>
> This code has all been redone for the new exception handling (which is
> complete), so it may be moot.
>
> I'll check into it.
In case it matters to you, I would not mind it if XML-Xerces only
worked for 5.6 and up. We are in the process of upgrading here.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: problems with 1.5.7 on dec_osf1
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"David Starks-Browning" <st...@ebi.ac.uk> writes:
> On 10 Oct 01, Jason E. Stewart writes:
>
> > Test this. Edit Xerces.C line 175 from:
> >
> > if (sv_derived_from(sv,s->name)) {
> >
> > to:
> >
> > if (sv_derived_from(sv,(char*)s->name)) {
>
> Thanks! That worked.
Ok, I'll make that change in my code.
> I get a number of failures during 'make test', though. I can't
> investigate further until tomorrow, but for now I get:
> > t/DOMException......dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED tests 2-7
> > Failed 6/7 tests, 14.29% okay
> > t/DOMParser.........Bareword "XML::Xerces::DOMParser" not allowed while "strict subs" in use at (eval 1) line 1.
> > FAILED test 3
> > Failed 1/9 tests, 88.89% okay
This was a mistake on my part. Perl 5.6 handles it ok, earlier
versions don't like it obviously. The eval " ... "; should be
eval { ... }; instead. Perl's eval has two very different purposes,
the first being to evaluate perl variables into code and executate
that code, the second form being to trap errors. I was intended the
trap errors version, but used the evaluate syntax. Now fixed.
> > t/IDOM_DOMException.dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED tests 2-6
> > Failed 5/6 tests, 16.67% okay
> > t/LocalFileInputSource.dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED tests 4-6
> > Failed 3/6 tests, 50.00% okay
> > t/MemBufInputSource.ok
> > t/PerlErrorHandler..ok
> > t/SAX2Count.........Use of uninitialized value at t/SAX2Count.t line 52.
> > Use of uninitialized value at t/SAX2Count.t line 53.
> > Use of uninitialized value at t/SAX2Count.t line 54.
> > Use of uninitialized value at t/SAX2Count.t line 55.
> > Use of uninitialized value at t/SAX2Count.t line 56.
> > Use of uninitialized value at t/SAX2Count.t line 57.
> > Use of uninitialized value at t/SAX2Count.t line 58.
> > Use of uninitialized value at t/SAX2Count.t line 59.
> > FAILED tests 2, 5
> > Failed 2/5 tests, 60.00% okay
> > t/SAXException......dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED tests 2-5
> > Failed 4/5 tests, 20.00% okay
> > t/URLInputSource....dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED test 7
> > Failed 1/7 tests, 85.71% okay
> > t/XMLException......dubious
> > Test returned status 0 (wstat 134, 0x86)
> > test program seems to have generated a core
> > DIED. FAILED tests 2-4
> > Failed 3/4 tests, 25.00% okay
All the rest seem to be associated with the code that I changed, which
is problematic. Presumably, there is something wrong with how I
implemented the usage of croak() for early versions of Perl.
This code has all been redone for the new exception handling (which is
complete), so it may be moot.
I'll check into it.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: problems with 1.5.7 on dec_osf1
Posted by David Starks-Browning <st...@ebi.ac.uk>.
On 10 Oct 01, Jason E. Stewart writes:
> > After commenting out the cxx definitions in hints/dec_osf1.pl (since
> > gcc should be able to handle C++ code), I get the following error in
> > "make":
> >
> > > gcc -c -I. -IHandler -I/sw/common/src/xerces-c_2001-10-05/alpha-osf1/include -D_REENTRANT -DHAS_BOOL -O3 -DVERSION=\"1.5.7\" -DXS_VERSION=\"1.5.7\" -fpic -I/sw/common/share/perl/5.00503/alpha-osf1/CORE Xerces.C
> > > Xerces.C: In function `struct swig_type_info * SWIG_TypeCheck(SV *, swig_type_info *)':
> > > Xerces.C:175: passing `const char *' as argument 2 of `Perl_sv_derived_from(SV *, char *)' discards qualifiers
> > > make: *** [Xerces.o] Error 1
> >
> > Is that a problem with my configuration or with Xerces.C?
>
> Looks like an issue with Xerces.C because the call to
> sv_derived_from() is inserted by me.
>
> Test this. Edit Xerces.C line 175 from:
>
> if (sv_derived_from(sv,s->name)) {
>
> to:
>
> if (sv_derived_from(sv,(char*)s->name)) {
Thanks! That worked. I get a number of failures during 'make test',
though. I can't investigate further until tomorrow, but for now I
get:
> make[1]: Entering directory `/cluster/members/member1/net/nfs0/vol1/sw/src/perl-modules/XML-Xerces-1.5.7/alpha-osf1/DOMParse'
> make[1]: Leaving directory `/cluster/members/member1/net/nfs0/vol1/sw/src/perl-modules/XML-Xerces-1.5.7/alpha-osf1/DOMParse'
> PERL_DL_NONLAZY=1 /sw/arch/bin/perl -Iblib/arch -Iblib/lib -I/sw/common/share/perl/5.00503/alpha-osf1 -I/sw/common/share/perl/5.00503 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
> t/DOMCount..........ok
> t/DOMCreate.........ok
> t/DOMException......dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED tests 2-7
> Failed 6/7 tests, 14.29% okay
> t/DOMParser.........Bareword "XML::Xerces::DOMParser" not allowed while "strict subs" in use at (eval 1) line 1.
> FAILED test 3
> Failed 1/9 tests, 88.89% okay
> t/DOMPrint..........ok
> t/DOM_Attr..........ok
> t/DOM_Element.......ok
> t/DOM_Entity........ Failed test 3 as expected, no worries
> ok
> t/DOM_NamedNodeMap..ok
> t/DOM_NodeList......ok
> t/EntityResolver....ok
> t/IDOMParser........Using /cluster/members/member1/net/nfs0/vol1/sw/src/perl-modules/XML-Xerces-1.5.7/alpha-osf1/blib
> ok
> t/IDOM_Attr.........ok
> t/IDOM_DOMException.dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED tests 2-6
> Failed 5/6 tests, 16.67% okay
> t/IDOM_Element......ok
> t/InputSource.......ok
> t/LocalFileInputSource.dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED tests 4-6
> Failed 3/6 tests, 50.00% okay
> t/MemBufInputSource.ok
> t/PerlErrorHandler..ok
> t/SAX2Count.........Use of uninitialized value at t/SAX2Count.t line 52.
> Use of uninitialized value at t/SAX2Count.t line 53.
> Use of uninitialized value at t/SAX2Count.t line 54.
> Use of uninitialized value at t/SAX2Count.t line 55.
> Use of uninitialized value at t/SAX2Count.t line 56.
> Use of uninitialized value at t/SAX2Count.t line 57.
> Use of uninitialized value at t/SAX2Count.t line 58.
> Use of uninitialized value at t/SAX2Count.t line 59.
> FAILED tests 2, 5
> Failed 2/5 tests, 60.00% okay
> t/SAXCount..........ok
> t/SAXException......dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED tests 2-5
> Failed 4/5 tests, 20.00% okay
> t/SAXParser.........ok
> t/Schema............ok
> t/StdInInputSource..ok
> t/URLInputSource....dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED test 7
> Failed 1/7 tests, 85.71% okay
> t/XMLException......dubious
> Test returned status 0 (wstat 134, 0x86)
> test program seems to have generated a core
> DIED. FAILED tests 2-4
> Failed 3/4 tests, 25.00% okay
> t/actualCast........ok
> t/domTest...........ok
> Failed Test Status Wstat Total Fail Failed List of failed
> -------------------------------------------------------------------------------
> t/DOMException. 0 134 7 6 85.71% 2-7
> t/DOMParser.t 9 1 11.11% 3
> t/IDOM_DOMExcep 0 134 6 5 83.33% 2-6
> t/LocalFileInpu 0 134 6 3 50.00% 4-6
> t/SAX2Count.t 5 2 40.00% 2, 5
> t/SAXException. 0 134 5 4 80.00% 2-5
> t/URLInputSourc 0 134 7 1 14.29% 7
> t/XMLException. 0 134 4 3 75.00% 2-4
> Failed 8/29 test scripts, 72.41% okay. 25/139 subtests failed, 82.01% okay.
> make: *** [test_dynamic] Error 2
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org
Re: problems with 1.5.7 on dec_osf1
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"David Starks-Browning" <st...@ebi.ac.uk> writes:
> Notice how hints/dec_osf.pl is processed twice, but seems not to make
> sense of it the first time.
Hey David,
It does things twice because I tell it to. The first time through I
check for libxerces on your system and if I don't find it, I exit.
> In my case, since perl was built with gcc but hints/dec_osf1.pl
> sepecifies cxx, I find that Handler/Makefile uses gcc, but Xerces.C
> is compiled with cxx. Does that make sense? I have no idea how to
> read Makefile.PL files, sorry!
Hmm.. No it doesn't. I must admit that I only discovered about hints
files recently while looking over how other C++ modules dealt with C++
compiler issues. The hints/ directory is the standard way to include
arch-specific information. It appears that I would need to have a
separate hints file for Handler as well.
If your perl was built with gcc, then you did the correct
thing. Makefile.PL files are just perl scripts, nothing strange about
them, except the final subrouting call to WriteMakefile() recursively
descends the directory structure writing Makefiles for all directories
with a Makefile.PL in it.
> After commenting out the cxx definitions in hints/dec_osf1.pl (since
> gcc should be able to handle C++ code), I get the following error in
> "make":
>
> > gcc -c -I. -IHandler -I/sw/common/src/xerces-c_2001-10-05/alpha-osf1/include -D_REENTRANT -DHAS_BOOL -O3 -DVERSION=\"1.5.7\" -DXS_VERSION=\"1.5.7\" -fpic -I/sw/common/share/perl/5.00503/alpha-osf1/CORE Xerces.C
> > Xerces.C: In function `struct swig_type_info * SWIG_TypeCheck(SV *, swig_type_info *)':
> > Xerces.C:175: passing `const char *' as argument 2 of `Perl_sv_derived_from(SV *, char *)' discards qualifiers
> > make: *** [Xerces.o] Error 1
>
> Is that a problem with my configuration or with Xerces.C?
Looks like an issue with Xerces.C because the call to
sv_derived_from() is inserted by me.
Test this. Edit Xerces.C line 175 from:
if (sv_derived_from(sv,s->name)) {
to:
if (sv_derived_from(sv,(char*)s->name)) {
or if g++ doesn't like that try
if (sv_derived_from(sv,const_cast<s->name>)) {
That way we tell the compiler it's OK to discard the const qualifier.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org