For some reason, my mail reader (pine) will not properly quote the
original message...
Anyway, the symbol problems are most likely caused by your build of the
Xerces libs, not the Perl extension. Unless you build Xerces exactly like
this:
$ sh runConfigure -paix -cxlc_r -xxlC_r -minmem -nsocket -tnative
^^^^^ ^^^^
BOOL doesn't get properly defined. You can use the c++filt utility
(comes with VAC and/or xlC) to demangle those symbols. For example:
$ c++filt checkXMLDecl__10XMLScannerFi
XMLScanner::checkXMLDecl(int)
$ c++filt checkXMLDecl__10XMLScannerFb
XMLScanner::checkXMLDecl(bool)
I'm betting you specified xlc and xlC rather than the '_r' variants,
causing the build to use a bool. This is really a workaround left over
from the older xlC "CSet" compiler which lacked built-in bool types.
In the long run, it doesn't so much matter whether you use int or bool in
Xerces, but the XML-Xerces extension had better agree with whatever does
get in there. Currently, it expects int.
That said, do not expect XML-Xerces to pass all of the regression tests.
It will dump core on many of the exception handler checks, and I have
never been able to figure out why. If you can actually convince the AIX
debugger (any of them) to trace execution properly, please let me know?
This has not prevented me from using XML-Xerces, but in the long run I'll
be forced to move over to the libxml2 parser unless I can figure out
what's causing the C++ exceptions to go astray...
Steve
--
----------------------------------------------------------------
Steven N. Hirsch tie-line: 446-6557 ext: 802-769-6557
Staff Engineer Methodology Integration Team
ASIC Product Development IBM Microelectronics
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
