[xsd-users] Using generated code on zLinux (s390x)

[Boris Kolpackov]

Hi Roger,

Roger Evans <roger at autodata.no> writes:

> I am trying to take the generated code .cxx and .hxx files along with my
> c-tree application and compile and link on Suse Linux SLE10 on IBM z/90
> under VM.   From the wiki, it looks as if this should work, since the
> "libxsd is a header-only runtime".   I take this to mean that I can copy
> the xsd header files (/include/xsd) to the s390x platform and use them
> in compiling my application.

Yes, this should work provided that (1) your can compile workable
Xerces-C++ on this platform and (2) the C++ compiler you are using
is modern enough to handle the runtime and generated code.

> I have downloaded built and installed xerces-c 2.8.0, compiled and
> linked my application, and it seems to work until I try to serialize.
> I get the following:
>
> roger at lnxnje:~/rf1037> ./rf1037
> terminate called after throwing an instance of
> 'xsd::cxx::tree::serialization<char>'
>   what():  serialization failed

I suggest that you catch and print this exception. This will give you
more information on what's going on:

try
{
  Skjema_ (std::cout,skj,map,"ISO-8859-15");
}
catch (const xml_schema::exception& e)
{
  cerr << e << endl;
}

My guess would be that the "ISO-8859-15" is not supported by your
build of Xerces-C++ on this platform (which you can fix by rebuilding
it with ICU as transcoder). For starters I would try to serialize
using an encoding for which Xerces-C++ has an intrinsic support,
for example, UTF-8.

> gdb gives the following:
>
> (gdb) r
>
> 168		xml_schema::namespace_infomap map;
> (gdb) n
> 169		map[""].name="http://www.brreg.no/or";
> (gdb) n
> 170		map[""].schema= "melding-669-7378.xsd";
> (gdb) n
> 171	        Skjema_ (std::cout,skj,map,"ISO-8859-15");
> (gdb) n
> terminate called after throwing an instance of
> 'xsd::cxx::tree::serialization<char>'
>   what():  serialization failed

Looks like on this platform stack is unwound as the handler is
being searched. As a result when no handler is found the stack
is completely unwound and useful debug information like where
the exception was thrown from is lost.

Boris