| Building Xerces-C++ on iSeries (AS/400) |
| The following addresses the requirements and build of Xerces-C++ natively on the iSeries.
| Building Xerces-C++ library |
| Requirements: OS/400 `QSHELL` interpreter installed (install base option 30, operating system) OS/400 - Portable App Solutions Environment (PASE) installed (install base option 33, operating system) iSeries Tools for Developers, PRPQ 5799-PTL (these are the gnu utilities) For v5: WebSphere Development ToolsSet, 5722-WDS ( installed option 52, Compiler - ILE C++) Recommendation: There is one option when building the XML4C parser on iSeries. For code page translation, you can use the iSeries native `Iconv400` support or `icu` as the transcoder plug in. If you choose ICU, follow the instructions to build the ICU service program with the ICU download. Those instructions are not included here. We recommend the use of `Iconv400`. Setup Instructions: Make sure that you have the requirements installed on your iSeries. We highly recommend that you read the write up that accompanies the iSeries Tools for Developers PRPQ. There are install instructions as well as information about how modules, programs and service programs can be created in Unix-like fashion using gnu utilities. Note that symbolic links are use in the file system to point to actual iSeries `*module`, `*pgm` and `*srvpgm` objects in libraries. Download the source zip file (NT version) directly to an iSeries IFS directory after creating a directory (eg. /XML4Cxxx) and then extract the source using a mapped drive. To do this, from Windows Explorer, select Tools -> Map Network Drive. Then select an available drive (e.g. F:) and specify an iSeries system you want to extract the zip file to (e.g. \\<your iSeries name>\root). Click on Finish. Then find the .zip file and right click on it and select Extract To ... Then select the files you want to extract to the iSeries system. Create iSeries target library. This library will be the target for the resulting modules and Xerces-C++ service program. You will specify this library on the OUTPUTDIR environment variable in step 4. Set up the following environment variables in your build process (use `ADDENVVAR` or `WRKENVVAR CL` commands):
    XERCESCROOT - <the full path up to the Xerces-C++ src directory, but not including 'src'>
    MAKE   - '/qibm/proddata/developertools/qsh/bin/gmake'
    OUTPUTDIR  - <identifies target iSeries library for *module, *pgm and *srvpgm objects>
    PATH   - '/usr/bin:/qibm/proddata/developertools/qsh/bin'
    ICUROOT - (if using ICU)  <the path of your ICU installation>
For v4r5m0 systems, add QCXXN, to your build process library list. This results in the resolution of CRTCPPMOD used by the icc compiler. You may want to put the environment variables and library list setup instructions in a `CL` program so you will not forget these steps during your build. Configure To configure the make files for an iSeries build do the following under Qsh:
    qsh:
    cd <full path to Xerces-C++>/src/xercesc
    edit runConfigure and comment out the line:
    	getoptErr=`getopt p:c:x:dm:n:t:r:b:l:z:P:C:h $*`
    runConfigure -p os400 -x icc -c icc -m inmem -t Iconv400 -r none
Troubleshooting:
    error: configure: error: installation or configuration problem:
    C compiler cannot create executables.
If during runConfigure you see the above error message, it can mean one of a few things. Either QCXXN is not on your library list OR the `runConfigure` cannot create the temporary modules (`CONFTest1`, etc) it uses to test out the compiler options or `PASE` is not installed. The second reason happens because the test modules already exist from a previous run of `runConfigure`. To correct the problem, do the following:
    CL:
    DLTMOD <OUTPUTDIR library>/CONFT* and
    DLTPGM <OUTPUTDIR library>/CONFT*
Build If runConfigure runs fine then do the following under Qsh to actually build the modules:
    qsh:
    cd <full path to Xerces-C++>/src/xercesc
    gmake
The above gmake should result in a service program being created in your specified library and a symbolic link to that service program placed in <path to Xerces-C++/lib>. It is highly possible that the service program will not create however due to number of modules and path names, see trouble shooting for the workaround. After the service program has successfully been created and a link established, you can either bind your XML application programs directly to the parser's service program via the `BNDSRVPGM` option on the `CRTPGM` or `CRTSRVPGM` command or you can specify a binding directory on your `icc` command. To specify an archive file to bind to, use the `-L, -l` binding options on icc. An archive file on iSeries is a binding directory. To create an archive file, use `qar` command. (see the iSeries Tools for Developers write up). After building the Xerces-C service program, create a binding directory by doing the following (note, this binding directory is used when building the samples. Also, note that the .a file below can have a different name based on the parser version (using apache xerces versioning)):
    qsh:
    cd <full path to Xerces-C++>/lib
    qar -cuv libxerces-c28.0.so *.o
    will results in
    command = CRTBNDDIR BNDDIR(yourlib/libxercesc) TEXT('/yourlib/Xerces-C++/lib/libxerces-c28.0.so')
    command = ADDBNDDIRE BNDDIR(yourlib/libxercesc) OBJ((yourlib/LIBXERCESC *SRVPGM) )
Troubleshooting gmake problem: Due to the number of modules (the .o symbolic links) that make up the service program and the path to get to those modules, the qshell ld request to create the service program will likely fail because the request is too large, you may get a message like the following at the end of the gmake request:
    FAILURE: spawnp()  with errno = 3491
    GMAKE: vfork: Argument list too long.
If this is the case, you can manually create the service program by doing the following:
    CL:
    CRTSRVPGM  (<OUTPUTDIR-library>/libxercesc)  MODULE(<OUTPUTDIR-library>/*ALL) EXPORT(*ALL) TEXT('XML4C parser version xxx')
    OPTION(*DUPPROC *DUPVAR *NOWARN) AUT(*USE)
Note that if you manually create the service program you want to make sure that you do not include any CONFT* modules or samples modules in the OUTPUTDIR library. After the service program is manually created you can add a symbolic link to the service program into the appropriate /lib directory by qsh:
    qsh:
    cd <full path to Xerces-C++>/lib
    ln -s /qsys.lib/<outputdir>.lib/libxercesc.srvpgm   libxerces-c28.0.so
    qar -cuv libxerces-c28.0.so *.o
If you are on a v4 system using the ILE C++ PRPQ compiler (which is referred to as the 'old' compiler) you will get compiler errors requiring a few manual changes to the source: src/xercesc/dom/impl/DOMDocumentImpl.cpp src/xercesc/dom/impl/DOMDocumentImpl.hpp src/xercesc/dom/deprecated/DocumentImpl.cpp src/xercesc/dom/deprecated/DocumentImpl.hpp src/xercesc/validators/common/ContentSpecNode.hpp Update the following routines in src/xercesc/dom/deprecated/DocumentImpl.cpp as follows:
     void DocumentImpl::setUserData(NodeImpl* n, void* data)
     {
    	if (!userData && data)
      #ifdef __OS400__
    		userData = new RefHashTableOf<char>(29, false, new HashPtr());
      #else
    		userData = new RefHashTableOf<void>(29, false, new HashPtr());
      #endif
    	if (!data && userData)
    		userData->removeKey((void*)n);
    	else
      #ifdef __OS400__
    		userData->put((void*)n,(char*)data);
      #else
    		userData->put((void*)n,data);
      #endif
     }

     void* DocumentImpl::getUserData(NodeImpl* n)
     {
    	if (userData)
      #ifdef __OS400__
    		return (void*)userData->get((void*)n);
      #else
    		return userData->get((void*)n);
      #endif
    	else
    		return null;
     }
To update src/xercesc/dom/deprecated/DoumentImpl.hpp as follows:
     #ifdef __OS400__
    	RefHashTableOf<char>		*userData;
     #else

    	RefHashTableOf<void>		*userData;
     #endif
Update the following routines in src/xercesc/dom/impl/DOMDocumentImpl.cpp as follows:
     void DOMDocumentImpl::setUserData(DOMNode* n, void* data)
     {
    	if (!fUserData && data)
     #ifdef __OS400__
    		fUserData = new (this) RefHashTableOf<char>(29, false, new (this) HashPtr());
     #else
    		fUserData = new (this) RefHashTableOf<void>(29, false, new (this) HashPtr());
     #endif

    	if (!data && fUserData)
    		fUserData->removeKey((void*)n);
    	else
     #ifdef __OS400__
    		fUserData->put((void*)n,(char*)data);
     #else
    		fUserData->put((void*)n,data);
     #endif
     }

     void* DOMDocumentImpl::getUserData(const DOMNode* n) const
     {
    	if (fUserData)
     #ifdef __OS400__
    		return (void*) fUserData->get((void*)n);
     #else
    		return fUserData->get((void*)n);
     #endif

    	else
    		return 0;
     }
To update src/xercesc/dom/impl/DOMDocumentImpl.hpp:
     #ifdef __OS400__
        RefHashTableOf<char>        *fUserData;
     #else
        RefHashTableOf<void>        *fUserData;
     #endif
Update validators/common/ContentSpecNode.hpp removing the following:
     #ifndef __OS400__
     inline
     #endif
     ContentSpecNode::~ContentSpecNode()
To build for transcoder ICU: Make sure you have an `ICUROOT` path set up so that you can find the ICU header files (usually `/usr/local`) Make sure you have created a binding directory (symbolic link) in the file system so that you can bind the Xerces-C++ service program to the ICU service program and specify that on the `EXTRA_LINK_OPTIONS` in `src/xercesc/Makefile.incl` (usually the default is a link in `/usr/local/lib`).
| Building Samples on iSeries |
| Note that the samples will create programs bind to the BND directory object created by qar referenced above.
    qsh
    cd <full path to Xerces-C++>/samples
    runConfigure -p os400 -x icc -c icc
    gmake
| Building Xerces-C++ on Macintosh |
| The Xerces-C++ Mac port has the key following attributes: Built atop CoreServices APIs and a limited number of Carbon APIs; supports builds for both Mac OS Classic, Carbon, and Mac OS X systems. Has a Mac OS native transcoder that utilizes the built-in Mac OS Unicode converter [MacOSUnicodeConverter]. Has two Mac OS native netaccessor classes. The first is based on Carbon and classic supported URLAccess and may be used in the broadest variety of configurations [MacOSURLAccess]. The second [MacOSURLAccessCF] is based on CFURLAccess, which requires either Carbon or Mac OS X CoreServices.framework. This second NetAccessor is useful in Mac OS X configurations where reliance on the full Carbon.framework would prohibit execution of the Xerces code in a remote context that has no access to the GUI. Supports builds from Metroworks CodeWarrior, Apple Xcode, and Mac OS X shell. Projects for Apple Project Builder are still included, but may not be up to date (you may need to revise the projects to accomodate recent file additions, deletions, or other changes in Xerces-C++).
| Using Xerces-C++ with CodeWarrior |
| Xerces-C++ and CodeWarrior: Xerces-C++ may be built with CodeWarrior under Mac OS Classic or Mac OS X. Since the Xerces-C++ code contains some files with very long names, and earlier versions of Mac OS, as well as earlier versions of CodeWarrior, did not support file names longer than 32 characters, CodeWarrior 8.0 is required. If you are building Xerces-C++ on a Mac OS 9 system, be extremely careful in how to unpack and/or transfer the Xerces-C++ files to that system, to ensure that their file names are not truncated in the process. Installing Xerces-C++ for use with CodeWarrior: Note: versions of CodeWarrior prior to 8.0 did not support HFS+ long file names, and thus required special steps to alter the file names prior to use. This restriction has been removed for CodeWarrior 8.0, and the projects now directly reference the unaltered source tree. The project files in this release require CodeWarrior v8.0 or higher. It is extemely important to ensure that you retrieve and unpack the sources with a tool that does not truncate file names. The command line gnutar utility on Mac OS X will do the right thing; older versions of StuffIt truncate names to 31 characters as they unpack tar archives, though versions >= 7.0.1 seem to work, at least on Mac OS X. The command line tool tar will truncate path names that get too long; gnutar should be used instead. Failure to heed these warnings will result in broken projects. Building Xerces-C++ with CodeWarrior: Run CodeWarrior (requires CodeWarrior 8.0 with support for long file names). Import the project Projects/MacOS/CodeWarrior/XercesLib/XercesLib.mcp.xml, saving it back out to the same directory as XercesLib.mcp. This project contains five build targets that build all combinations of classic, carbon, debug, and release versions, with an all target that builds all of these. Build any or all of these. Building Xerces-C++ Samples with CodeWarrior: A CodeWarrior project is included that builds the DOMPrint sample. This may be used as an example from which to build additional sample projects. Please read the following important notes: Once again, it is required that you import the .xml version of the project file, and save it back out. The Xerces-C++ sample programs are written to assume a command line interface. To avoid making Macintosh-specific changes to these command line programs, we have opted to instead require that you make a small extension to your CodeWarrior runtime that supports such command line programs. Please read and follow the usage notes in XercesSampleSupport/XercesSampleStartupFragment.c.
| Building Xerces-C++ with Xcode |
| Projects are included to build the Xerces-C++ library and DOMPrint sample under Apple's Xcode for Mac OS X. The following notes apply: Be sure to heed warnings under "special instructions" below regarding which tools must be used to unpack archives: gnutar is your friend. The Xcode project builds XercesLib as the framework Xerces.framework. This framework, however, does not currently include a correct set of public headers. Any referencing code must have an include path directive that points into the Xerces-C++ src directory. The DOMPrint project illustrates one such usage of the Xerces.framework.
| Building Xerces-C++ from the Mac OS X command line |
| Support for Mac OS X command line builds is now included in the standard "unix" Xerces-C++ build infrastructure. In general, the Mac OS X command line build follows the generic unix build instructions. You need to set your XERCESCROOT environment variable (the full path up to the Xerces-C++ src directory, but not including 'src'), `./runConfigure`, and `make`. Be sure to heed warnings under "special instructions" below regarding which tools must be used to unpack archives: gnutar is your friend.
    export XERCESCROOT="<xerces-c-directory>"
    cd src/xercesc
    ./runConfigure -p macosx -n native -t native
    make
Similar instructions apply to build the samples and tests, though the `-n` and `-t` flags are not used in these cases:
    cd samples
    ./runConfigure -p macosx
    make
| Special usage information for Xerces-C++ on the Macintosh |
| Unpacking the tar archive It is extemely important to ensure that you retrieve and unpack the sources with a tool that does not truncate file names. The command line gnutar utility on Mac OS X will do the right thing; older versions of StuffIt truncate names to 31 characters as they unpack tar archives, though versions >= 7.0.1 seem to work, at least on Mac OS X. The command line tool tar will truncate path names that get too long; gnutar should be used instead. Failure to heed these warnings will result in broken projects. File Path Specification Apart from the build instructions, above, the most important note about use of Xerces-C++ on the Macintosh is that Xerces-C++ expects all filename paths to be specified in unix syntax. If running natively under a Mac OS X system, this path will be the standard posix path as expected by the shell. The easiest means of creating and interpreting these paths will be through the routines `XMLCreateFullPathFromFSRef` and `XMLParsePathToFSRef` as declared in the file `MacOSPlatformUtils.hpp`. `FSSpec` variants of these routines are also supplied. Mac OS Version Compatibility Xerces-C++ requires that several key components of the Mac OS be relatively up to date. It should be readily compatible with any system above Mac OS 9.0. Compatibility with earlier systems may perhaps be achieved if you can install appropriate components. Required components are: Unicode Converter and Text Encoding Converter. These provide the base transcoding service used to support Xerces-C++ transcoding requirements. Optional components are: URLAccess. Provides NetAccessor support to Xerces-C++ for use in fetching network referenced entities. If URLAccess is not installed, any such references will fail; the absence of URLAccess, however, will not in itself prevent Xerces-C++ from running. If Xerces-C++ is configured to use MacOSURLAccessCF, then URLAccess (and thus Carbon) is not required, but CoreServices.framework is required for Mac OS X. Multiprocessing library. Provides mutual exclusion support. Once again, the routines will back down gracefully if Multiprocessing support is not available. HFS+ APIs. If HFS+ APIs are available, all file access is performed using the HFS+ fork APIs to support long file access, and to support long Unicode compliant file names. In the absence of HFS+ APIs, classic HFS APIs are used instead.

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