Hi,
Here is a better explanation of why the link is failing (ie. a continuation
of my previous response). The file
util/Platforms/OS390/OS390PlatformUtils.cpp is including
Iconv390TransService.hpp. However, the Makefile in the util directory is
not compiling the Iconv390 directory but rather the Iconv directory (Iconv
= native). So Iconv390TransService will be unresolved as it never gets
built. I can't explain why building statically with your app works as you
should need the Iconv390TransService.o which doesn't exist...
If you modify the OS390PlatformUtils.cpp source file to use
#include <xercesc/util/Transcoders/Iconv/IconvTransService.hpp>
as the default does that work (ie. both build and execute okay)? To be
honest, I am not sure if it will or not. Iconv390 doesn't work which is
why it was taken away as an option in runConfigure - we should of also
updated the Makefile and OS390PlatformUtils.cpp and deleted the Iconv390
directory but that was an oversight. I can fix these problems but it isn't
clear to me what the default Transcoder should be for OS/390. If native
works we can use that, if not I will have to issue a #error (meaning that
for 390 either ICU or Uniconv390 must be used), unless someone is able to
get Iconv (or Iconv390) working on 390...
Btw, the toolkit uses the Uniconv390 transcoder, which does use ICU...
No need to apologize... I knew what you meant...
Regards,
David A. Cargill
XML Parser Development
IBM Toronto Lab
(905) 413-2371, tie 969
[EMAIL PROTECTED]
"blatt, lew"
<[EMAIL PROTECTED]
m> To
"'xerces-c-dev@xml.apache.org'"
04/06/2005 12:50 <xerces-c-dev@xml.apache.org>
PM cc
Subject
Please respond to RE: zOS Xerces 2.6 build problem
xerces-c-dev
Thanks, David, for the quick turn-round. I was hoping the thread would
engage you. Previous build errors, zOS/OS400, aim back to you :)
The puzzler to me is that binding the Xerces objects statically fails, but
binding with my app succeeds ! Below is a snip of the failure and below
the
failure is a snip showing the symbols found when I statically link the
Xerces .o files with my app (using traditional batch jcl) ! Your other
suggs re ICU and toolkit are good advice and I conclude my email with
comments.
FAILURE:
Building /u/agroccia/lewXerces/xerces-c-src_2_6_0/lib/libxerces-c2_6_0.dll
IEW2456E 9207 SYMBOL __ct__Q2_11xercesc_2_220Iconv390TransServiceFv
UNRESOLVED.
MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
FSUM3065 The LINKEDIT step ended with return code 8.
gmake[1]: ***
[/u/agroccia/lewXerces/xerces-c-src_2_6_0/lib/libxerces-c2_6_0.dll
] Error 3
Building
/u/agroccia/lewXerces/xerces-c-src_2_6_0/lib/libxerces-depdom2_6_0.dll
IEW2456E 9207 SYMBOL
fgArrayIndexOutOfBoundsException_Name__Q2_11xercesc_2_26XMLUni
UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED
SUCCESS:
__ct__Q2_-viceFv := __ct__Q2_11xercesc_2_220Iconv390TransServiceFv
$$DEMANGLED$$ ==
xercesc_2_2::Iconv390TransService::Iconv390TransService()
fgArrayIn-XMLUni :=
fgArrayIndexOutOfBoundsException_Name__Q2_11xercesc_2_26XMLUni
$$DEMANGLED$$ ==
xercesc_2_2::XMLUni::fgArrayIndexOutOfBoundsException_Name
Yes, the toolkit is an option that has been used successfully. It would be
helpful to know what the defaults taken to build the toolkit are
(transcoder,...). In any event, we'd like to emulate our non-zOS brothers
&
sisters, if possible, in our distribution, hence the desire to produce the
library ourselves.
I prefer, out of ignorance, aiming for a solution not involving ICU. It's
been unclear (albeit thru cursory inspection only) how ICU fits. All I saw
was the 8+MB distribution and saw a whole nother learning curve.
Thanks again, lew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
