http://xml.apache.org/http://www.apache.org/http://www.w3.org/

Xerces Project

Overview
Charter
Release Info
Download

Xerces-C++ 3.1.1
Installation
Build Instructions

Programming
Samples
FAQs

API Reference
DOM C++ Binding
Migration Guide

Xerces-C++ 2.8.0
Installation
Build Instructions

Programming
Samples
FAQs

API Reference
DOM C++ Binding
Migration Guide

Feedback
Bug-Reporting
Mailing Lists

Source Repository
Applications

Questions
 


Why do I get compilation error saying undeclared identifier or class undefined?
 

Xerces-C++ 2.8.0 now supports C++ Namespace.

If C++ Namespace is ENABLED, users' applications must namespace qualify all the Xerces-C++ classes, data, and variables with XERCES_CPP_NAMESPACE_QUALIFIER or add the XERCES_CPP_NAMESPACE_USE clause. Users also need to ensure all forward declarations are properly qualified or scoped.

See the Programming Guide Using C++ Namespace for details.


Why do I get compilation error saying DOMDocument was declared twice using Microsoft Visual C++.Net?
 

Your application somehow has picked up the Microsoft SDK header Msxml.h which has its own typedef of DOMDocument. This confuses with the Xerces-C++ 2.8.0 xercesc::DOMDocument and thus lead to the compilation errors.

Qualifier the use of DOMDocument in your application explicitly e.g.

XERCES_CPP_NAMESPACE_QUALIFIER DOMDocument * fDoc;

will eliminate these compilation problems.


Why can't the compiler find the include files?
 

A common cause for this problem is setting build environment variable XERCESROOT instead of setting variable XERCESCROOT. Note the C before ROOT.


Why do I get Internal Compiler Error when compiling Xerces-C++ for a 64bit target with gcc?
 

This is a compiler problem. Try turning off optimization to bypass the problem.


Why do I get compilation error when compiling Xerces-C++ on FreeBSD with native transcoder?
 

Please make sure you configure with "-t IconvFBSD" to use FreeBSD specific native transcoder.

Or you can use ICU transcoder (configure with -t icu) instead of the native transcoder.


Building Xerces-C++ with compiler GCC 2.7.x or 2.8.x gives problem, what's wrong?
 

Users using GCC 2.7.x or 2.8.x may have unsuccessful compile/link/run experience with Xerces-C++. There were issues related to templates and multi threaded exception handling with this old version GCC compiler.

Please upgrade to at least GCC 2.95.2.


Why does my application give unresolved linking errors?
 

Please check the following:

  1. If you're using the binary build of Xerces-C++, make sure that the OS and compiler are the same version as the ones used to build the binary. Different OS and compiler versions might cause unresolved linking problems or compilation errors. If the versions are different, rebuild the Xerces-C++ library on your system before building your application. If you're using ICU (which is packaged with XML4C) you need to rebuild the compatible version of ICU first.
  2. Check that the library path is set properly and that the correct versions of gmake and autoconf are on your system.
  3. If C++ Namespace support is ENABLED (all the binary distributions of Xerces-C++ 2.8.0 are built with C++ Namespace enabled), users' applications must namespace qualify all the Xerces-C++ classes, data and variables. See the Programming Guide Using C++ Namespace for details.

Why do I get link error saying icudata library not found when building with ICU?
 

There is a bug in the Makefile of ICU 1.7, 1.8 and 1.8.1. The link created during ICU installation in $ICUROOT is, for example,

icudata.so@ -> icudt17l.so

instead of

libicudata.so@ -> libicudt17l.so

Therefore the -licudata doesn't work. To bypass the problem, please manually create the following link:

libicudata.so@ -> libicudt17l.so

This problem has been fixed in ICU 2.0.


I cannot run the sample applications. What is wrong?
 

In order to run an application built using Xerces you must set up your path and library search path properly. In the stand-alone version from Apache, you must have the Xerces-C++ runtime library available from your path settings.

On Windows this library is called xerces-c_2_8.dll which must be available from your PATH settings. (Note that there are separate debug and release dlls for Windows. The release dll is named xerces-c_2_8.dll, and the debug dll is named xerces-c_2_8d.dll).

On UNIX platforms the library is called libxerces-c.so.28.0 (or libxerces-c28.0.so or libxerces-c.sl.28.0) which must be available from your LD_LIBRARY_PATH (or LIBPATH or SHLIB_PATH) environment variable.

Thus, if you installed your binaries under $HOME/fastxmlparser, you need to point your library path to that directory.

export LIBPATH=$LIBPATH:$HOME/fastxmlparser/lib # (AIX)
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/fastxmlparser/lib # (Solaris, Linux)
export SHLIB_PATH=$SHLIB_PATH:$HOME/fastxmlparser/lib # (HP-UX)

If you are using the XML4C parser from IBM, you will need to put in two additional DLLs. In the Windows build these are icuuc*.dll and icudt*.dll which must be available from your PATH settings. On UNIX, these libraries are called libicuuc*.so and libicudt*.so (or .sl for HP-UX or .a for AIX) which must be available from your library search path.

If the parser is built with icu message loader (as mentioned above), or message catalog loader, you need an environment variable, XERCESC_NLS_HOME to point to the directory, $XERCESCROOT/msg, where the message files reside.


Why does my application crash on AIX when I run it under a multi-threaded environment?
 

AIX maintains two kinds of libraries on the system, thread-safe and non-thread safe. Multi-threaded libraries on AIX follow a different naming convention, Usually the multi-threaded library names are followed with "_r". For example, libc.a is single threaded whereas libc_r.a is multi-threaded.

To make your multi-threaded application run on AIX, you must ensure that you do not have a "system library path" in your LIBPATH environment variable when you run the application. The appropriate libraries (threaded or non-threaded) are automatically picked up at runtime. An application usually crashes when you build your application for multi-threaded operation but don't point to the thread-safe version of the system libraries. For example, LIBPATH can be simply set as:

LIBPATH=$HOME/<Xerces>/lib

Where <Xerces> points to the directory where the Xerces application resides.

If, for any reason unrelated to Xerces, you need to keep a "system library path" in your LIBPATH environment variable, you must make sure that you have placed the thread-safe path before you specify the normal system path. For example, you must place /lib/threads before /lib in your LIBPATH variable. That is to say your LIBPATH may look like this:

export LIBPATH=$HOME/<Xerces>/lib:/usr/lib/threads:/usr/lib

Where /usr/lib is where your system libraries are.


Why does my multi-threaded application crash on Solaris 2.6?
 

The problem appears because the throw call on Solaris 2.6 is not multi-thread safe. Sun Microsystems provides a patch to solve this problem. To get the latest patch for solving this problem, go to SunSolve.sun.com and get the appropriate patch for your operating system. For Intel machines running Solaris, you need to get Patch ID 104678. For SPARC machines you need to get Patch ID #105591.


I just built my own application using the Xerces-C++ parser. Why does it crash?
 

In order to work with the Xerces-C++ parser, you have to first initialize the XML subsystem. The most common mistake is to forget this initialization. Before you make any calls to Xerces-C++ APIs, you must call XMLPlatformUtils::Initialize():

try {
   XMLPlatformUtils::Initialize();
}
catch (const XMLException& toCatch) {
   // Do your failure processing here
}

This initializes the Xerces system and sets its internal variables. Note that you must the include xercesc/util/PlatformUtils.hpp file for this to work.


Why does deleting a transcoded string result in assertion on windows?
 

Both your application program and the Xerces-C++ DLL must use the same *DLL* version of the runtime library. If either statically links to the runtime library, the problem will still occur.

For example, for a Win32/VC6 build, the runtime library build setting MUST be "Multithreaded DLL" for release builds and "Debug Multithreaded DLL" for debug builds.

Or for example for a Win32/BCB6 build, application need to switch to Multithreaded runtime to avoid such memory access violation.

To bypass such problem, instead of calling operator delete[] directly, you can use the provided function XMLString::release to delete any string that was allocated by the parser. This will ensure the string is allocated and deleted by the same DLL and such assertion problem should be resolved.


The libs/dll's I downloaded keep me from using the debugger in VC6.0. I am using the 'D', debug versions of them. "no symbolic information found" is what it says. Do I have to compile everything from source to make it work?
 

Unless you have the .pdb files, all you are getting with the debug library is that it uses the debug heap manager, so that you can compile your stuff in debug mode and not be dangerous. If you want full symbolic info for the Xerces-C++ library, you'll need the .pdb files, and to get those, you'll need to rebuild the Xerces-C++ library.


First-chance exception in DOMPrint.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception. I am always getting this message when I am using the parser. My programs are terminating abnormally. Even the samples are giving this exception. I am using Visual C++ 6.0 with latest service pack installed.
 

Xerces-C++ uses C++ exceptions internally, as part of its normal operation. By default, the MSVC debugger will stop on each of these with the "First-chance exception ..." message.

To stop this from happening do this:

  • start debugging (so the debug menu appears)
  • from the debug menu select "Exceptions"
  • from the box that opens select "Microsoft C++ Exception" and set it to "Stop if not handled" instead of "stop always".

You'll still land in the debugger if your program is terminating abnormally, but it will be at your problem, not from the internal Xerces-C++ exceptions.


Fatal Error: Cannot open include file: XXX: No such file or directory
 

Due to the recent directory change, you may need to either update your project file, makefile, or your source/header file, for details, please refer to Directory Change.


Cannot load message domain, Xerces Panic Error?
 

If the parser is built with icu message loader (like IBM XML4C binaries), you need to make sure that the message library (for the exact name see FAQ: Which DLLs do I need to distribute with my application?) is located in a directory which is on the library search path. Or the message resource file, XercesMessages_en_US.res, is in the directory given at the call to XMLPlatformUtils::Initialize(), or is located in the directory pointed to by the environment variable XERCESC_NLS_HOME, or at $XERCESCROOT/msg.

If the parser is built with message catalog loader, you need to make sure that the message catalog file, XercesMessages_en_US.cat, is in the directory given at the call to XMLPlatformUtils::Initialize(), or is located in the directory pointed to by the environment variable XERCESC_NLS_HOME, or at $XERCESCROOT/msg.


Why my document is valid on some platform while invalid on others?
 

The parser relies on the system call, strtod(), to parse a string representation of a double/float data. In the case of no invalid characters found, the strtod() returns a double/float value if it is representable on that platform, or raises ERANGE to indicate either underflow or underflow occurs. And the parser assigns zero to the said data if underflow is found.

The threshold, where the strtod() decides if an underflow occurs, varies on platforms. On windows, it is roughly the order of e-308, on Linux, e-325, and on AIX, HP and Solaris, e-324.

So in an instance document, a data of value 1.0e-310 from a type with minExclusive 0, is considered invalid on windows (since it is converted to 0 and therefore violates the minExclusive constraint), but valid on other unix platforms (since it remains the original value).

The discussion above applies to data in xsd file as well.


How do I regenerate the documentation?
 

To use the internal XML based application that creates the documentation, you must have a Java Virtual machine installed on your system. The application itself, written in Java, is provided in the xerces-c-tools_2_8_0 distribution. You should copy its contents into your $XERCESCROOT directory.

To regenerate the documentation, go to directory $XERCESCROOT and start createDocs.sh (for Unix) or createdocs.bat (for Windows). The result can be found in directory $XERCESCROOT/doc/html.

To regenerate the API documentation, you need to have at least Doxygen installed on your system.

If you want the API documentation to contain dependency graphs, you also need to have GraphViz installed on your system.

If you do not have GraphViz, or do not want to use it, you have to edit file $XERCESCROOT/doc/Doxyfile and change HAVE_DOT = YES into HAVE_DOT = NO.

To actually regenerate the API documentation, go to directory $XERCESCROOT/doc/ and start Doxygen. The result can be found in directory $XERCESCROOT/doc/html/apiDocs.



Copyright © 1999-2010 The Apache Software Foundation. All Rights Reserved.