RE: Building the XML parser on SunOS 5.6 with Workshop 6.0 (C++ 5 .2)

["Majeed, Zartaj" <za...@kanisa.com>]

It looks like you have unzipped or untar'd a source copy
meant for Windows. I downloaded xerces-c-src1_4_0.tar.gz from

http://xml.apache.org/dist/xerces-c/stable/

and was able to build as described below.

Zartaj
-----Original Message-----
From: Fariborz Jahanian [mailto:fjahanian@verisign.com]
Sent: Tuesday, March 13, 2001 5:00 PM
To: 'xerces-c-dev@xml.apache.org'
Cc: Fariborz Jahanian
Subject: Building the XML parser on SunOS 5.6 with Workshop 6.0 (C++
5.2)



Hello,
	I am trying to build the parser in the above platform, but I don't
get too far. Problem I am having is
	that the Makefiles' that runConfigure produces all have
carriage-return, '\r', to end a line. gnumake cannot
	handle this and fails. This is the runConfigure options I use:

	sh runConfigure -psolaris -ccc -xCC -minmem -nfileonly -tnative

	both cc and CC are on my path, but they are not relevent to my
problem.

	Also, has anyone been able to port the parser to  Workshop 6.0 (C++
5.2) ? Since Workshop6.0 is
	now in widespread use, the released XML-parser built with
Workshop4.2 is not usable.

	- Thanks, Fariborz Jahanian
	  fjahanian@verisign.com



---------------------------------------------------------------------
Here's a mail I sent to the list a few days ago:

I managed to build and run testXSLT v.1.1.0 using Forte C++ 6 Update 1 on
Solaris 8 10/00 which involved building libxerces-c1_4.so and
libxalan-c1_1.so on the same platform.
Since there are no recent archives of this mailing list or of xerces-c-dev,
I don't know if somebody has already posted this information but here's 
what I did.

I built libxerces-c1_4.so by downloading its source separately and typing:
runConfigure -d -p solaris -c cc -x CC; make

Then I copied libxerces-c1_4.that I had built to xml-xerces/c/lib and 
xml-xalan/c/lib.

Building libxalan-c1_1.so required some source changes:

1. xml-xalan/c/src/Include/SolarisDefinitions.hpp:
Various macros no longer need be defined. The ones I kept are:
#define XALAN_XALANDOMCHAR_USHORT_MISMATCH 
// since wchar_t on Solaris is 32 bits
#define XALAN_BIG_ENDIAN
And looking at the definitions file for other platforms, I decided to add:
#define XALAN_LSTRSUPPORT // I guess this means wide literals L"" support?
If not, then what?
#define XALAN_FULL_WCHAR_SUPPORT
#define XALAN_RTTI_AVAILABLE
I also had to keep:
#define XALAN_NO_STD_ALLOCATORS
because without it I got the error:
./PlatformSupport/ArenaBlock.hpp:198: Error: Cannot assign void* to
XalanSourceTreeAttr*.
This seemed to be caused by std::allocator::allocate returning void * 
which should not be happening but since defining XALAN_NO_STD_ALLOCATORS 
made the error disappear, I did not investigate it further.

2. Above changes resulted in the following compile error for
XalanTransformer/XalanCAPI.cpp:
"./XalanTransformer/XalanTransformerOutputStream.hpp", line 72: Error:
Multiple declaration for XalanOutputHandlerType.
"./XalanTransformer/XalanTransformerOutputStream.hpp", line 76: Error:
Multiple declaration for XalanFlushHandlerType.

This was due to XalanOutputHandlerType defined in both
XalanTransformerOutputStream.hpp
and XalanCAPI.h. The two header files were then being included in
XalanCAPI.cpp.

Ostensibly the compiler should have not complained because the definition
for XalanOutputHandlerType was extern "C" in XalanCAPI.h and not 
extern "C" in XalanTransformerOutputStream.hpp. But Forte
treated them as the same type. So I took the definitions out of the extern
"C" block in XalanCAPI.h and guarded them against multiple inclusion in 
both header files with:

#ifndef XALAN_OUTPUT_HANDLER_TYPE
typedef unsigned long (*XalanOutputHandlerType) (const void*, unsigned long,
const void*);
#define XALAN_OUTPUT_HANDLER_TYPE
#endif
#ifndef XALAN_FLUSH_HANDLER_TYPE
typedef void (*XalanFlushHandlerType) (const void*);
#define XALAN_FLUSH_HANDLER_TYPE
#endif

Taking them out of the extern "C" block helped because otherwise 
the linker complained about either the extern "C" typedef missing 
or the other typedef missing depending on which typedef
was included first.

3. Another point to note is Forte C++ 6 ships with RogueWave's C++ 
standard library so there is no need to follow any directions about 
using STLport.

4. testXSLT ran successfully on a simple example.

Zartaj

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org