Additional to all that I think you need to set your library path to where the
icu library resides. Most probably it'd be in <icu>/lib. So add this to your
LD_LIBARARY_PATH.
Message Catalog is also not yet implemented for Linux. So, inmem should do the
job for now.

Arundhati

Anupam Bagchi wrote:

> Try using
>
> ./runConfigure -plinux -cgcc -xg++ -minmem -nfileonly -ticu
>
> The ICU message loader is not yet implemented. The error message regarding
> "conf.h" is harmless on UNIX and was inserted to satisfy AS/400! Rest of
> your setting appears OK to me.
>
> - Anupam
> ================================================
> Anupam Bagchi
> Advisory Software Engineer
> XML Development Group, IBM Cupertino
> Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Phone: 408-777-5842
> ================================================
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 29, 2000 11:55 AM
> Subject: Re: Cannot compile Xerces-C 1.1.0 d15 under Linux
>
> I'm not the Linux dude, so hopefully someone else will give you a more
> complete answer... but one obvious issue is that the ICU message loader
> really shouldn't be getting used. Its not really implemented, and you'd
> really want to use the message catalog message loader on Linux, I would
> think. To just get going you could always first use the InMemory message
> loader, then figure out how to get the message catalog one working after
> you get everything else happy.
>
> How to go about doing that in the build infrastructure, I haven't a clue
> since I only knows Windows. But at least that's the 10,000 foot level
> answer anyway :-)
>
> ----------------------------------------
> Dean Roddey
> Software Weenie
> IBM Center for Java Technology - Silicon Valley
> [EMAIL PROTECTED]
>
> Konrad Gawry�
> <[EMAIL PROTECTED]>@linux.millionzillion.com.pl on
> 02/29/2000 06:11:09 AM
>
> Please respond to [EMAIL PROTECTED]
>
> Sent by:  [EMAIL PROTECTED]
>
> To:   [EMAIL PROTECTED]
> cc:
> Subject:  Cannot compile Xerces-C 1.1.0 d15 under Linux
>
> Hi there
>
> I've been trying to compile the latest Xerces-C under Linux, but
> unfortunately I haven't managed it yet.
>
> Before I go to the details, I'd like to underline the fact that I want
> to compile Xerces-C with support for ICU libraries. I want it this way
> because I'd also like to parse XML documents with data encoded in
> ISO-8859-2 standard.
>
> First of all, I compiled and installed ICU 1.4 libraries. It went
> without any problems. Please notice that instructions on page
> http://xml.apache.org/xerces-c/build.html regarding building ICU libs
> for Xerces-C are no longer valid because it is not enough to perform
> "make" and "make install" in "common" and "tools/makeconv" directories.
>
> Having built ICU libraries I tried to build Xerces-C 1.1.0 d15 itself. I
> modified line 501 in "runConfigure" by adding "--prefix" parameter
> script to ensure that built software will be installed in the right
> place. After setting XERCESCROOT, ICUROOT and ICU_DATA I ran
>
> ./runConfigure -plinux -cgcc -xg++ -micu -ticu
>
> At first the script printed an error message informing about lack of
> "conf.h.in" file, but I created a symbolic link to "config.h.in" (was
> that right?) and the second run of "runConfigure" completed without any
> problems.
>
> Having done that I tried to build Xerces-C by running "make". There were
> two problems with it:
>
> 1. During the building process the following error occured:
>
> cd MsgLoaders/ICU ; make ; cd ../..
> make[2]: Entering directory
> `/home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/src/util/MsgL
> oaders/ICU'
>
> mkdir -p
> /home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/include/util/M
> sgLoaders/ICU
>
> cp -fp ICUMsgLoader.hpp
> /home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/include/util/M
> sgLoaders/ICU
>
> g++ -fpic -instances=static -DLINUX -D_REENTRANT -c -O
> -DXML_USE_ICU_TRANSCODER -I/home/konrad/xml/include
> -DXML_USE_ICU_MESSAGELOADER
> -I/home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/include
> -o ICUMsgLoader.o ICUMsgLoader.cpp
> ICUMsgLoader.cpp:86: resbund.h: No such file or directory
> make[2]: *** [ICUMsgLoader.o] Error 1
> make[2]: Leaving directory
> `/home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/src/util/MsgL
> oaders/ICU'
>
> This error, however, didn't stop the building process.
>
> 2. Another error (fatal this time) ocurred at the end, when the
> libxerces-c1_1.so shared library should be built.
>
> /usr/bin/ld: cannot open -licudata: No such file or directory
> collect2: ld returned 1 exit status
> make[1]: ***
> [/home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/lib/libxerces
> -c1_1.so]
>
> Error 1
> make[1]: Target `ALL' not remade because of errors.
> make[1]: Leaving directory
> `/home/konrad/xml/build_source_directory/xerces-csrc_1_1_0_d15/obj'
>
> The second problem was easy to eliminate, because a symbolic link solved
> it. It's a bit strange, however, that libicudata.so wasn't installed in
> "lib" subdirectory of ICU install directory. It was installed in
> "share/icu/1.4.0" subdirectory.
>
> I couldn't eliminate the first problem, though. I tried to modify
> "ICUMsgLoader.cpp" and correct the include directive by including
> "unicode/resbund.h" instead of "resbund.h", but it resulted in other
> errors:
>
> ICUMsgLoader.cpp: In method `ICUMsgLoader::ICUMsgLoader(const XMLCh *)':
>
> ICUMsgLoader.cpp:110: `tmpPath' undeclared (first use this function)
> ICUMsgLoader.cpp:110: (Each undeclared identifier is reported only once
> ICUMsgLoader.cpp:110: for each function it appears in.)
> ICUMsgLoader.cpp: In method `bool ICUMsgLoader::loadMsg(unsigned int,
> XMLCh *, long unsigned int)':
> ICUMsgLoader.cpp:142: no matching function for call to
> `UnicodeString::UnicodeString (const XMLCh *const &)'
> /home/konrad/xml/include/unicode/unistr.h:1294: candidates are:
> UnicodeString::UnicodeString()
> /home/konrad/xml/include/unicode/unistr.h:1302:
> UnicodeString::UnicodeString(int32_t)
> /home/konrad/xml/include/unicode/unistr.h:1308:
> UnicodeString::UnicodeString(UChar)
> /home/konrad/xml/include/unicode/unistr.h:1315:
> UnicodeString::UnicodeString(const UChar *)
> /home/konrad/xml/include/unicode/unistr.h:1324:
> UnicodeString::UnicodeString(const UChar *, int32_t)
> /home/konrad/xml/include/unicode/unistr.h:1343:
> UnicodeString::UnicodeString(bool_t, UChar *, int32_t)
> /home/konrad/xml/include/unicode/unistr.h:1356:
> UnicodeString::UnicodeString(const char *, const char *)
> /home/konrad/xml/include/unicode/unistr.h:1371:
> UnicodeString::UnicodeString(const char *, int32_t, const char *)
> /home/konrad/xml/include/unicode/unistr.h:1603:
> UnicodeString::UnicodeString(const UnicodeString &)
> /home/konrad/xml/include/unicode/unistr.h:1577:
> UnicodeString::UnicodeString(UChar *, int32_t, int32_t)
> ICUMsgLoader.cpp:143: no matching function for call to
> `ResourceBundle::getString (UnicodeString &, UErrorCode &)'
> /home/konrad/xml/include/unicode/resbund.h:217: candidates are:
> ResourceBundle::getString(const char *, UnicodeString &, UErrorCode &)
> const
> /home/konrad/xml/include/unicode/resbund.h:231:
> ResourceBundle::getString(const char *, UErrorCode &) const
> ICUMsgLoader.cpp:155: no matching function for call to
> `UnicodeString::extract (int, const unsigned int &, XMLCh *const &)
> const'
> /home/konrad/xml/include/unicode/unistr.h:1950: candidates are:
> UnicodeString::extract(UTextOffset, int32_t, UChar *, UTextOffset) const
>
> /home/konrad/xml/include/unicode/unistr.h:1956:
> UnicodeString::extract(UTextOffset, int32_t, UnicodeString &) const
> /home/konrad/xml/include/unicode/unistr.h:707:
> UnicodeString::extract(UTextOffset, int32_t, char *, const char *) const
>
> make: *** [ICUMsgLoader.o] Error 1
>
> Is there any way to overcome it? It seems that for now I'll have to
> stick to Xerces-C 1.0.1 and ICU 1.3.1.
>
> BTW, I'm using Linux (RedHat 6.1 distro + updates), kernel version
> 2.2.14.
>
> Thanks in advance for help.
>
> Konrad Gawry�
> MillionZillion Software sp. z o.o.
> http://www.millionzillion.com.pl/

Reply via email to