Build problems in i386 linux

[Alberto Manuel Brandao Simoes]

Hi

I am not needing parrot (just checking its state) but compilation
failed. Don't know if it is expected or not. In any case, this might be
useful:

../data/locales/ja.txt:15: parse error. Stopped parsing with
U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR
make[1]: *** [../data/out/build/icudt26l_ja.res] Error 3
make[1]: Leaving directory `/home/ambs/Junk/Parrot/parrot/icu/source/data'
make: *** [blib/lib/libicuuc.a] Error 2

Cheers
Alberto

[Stéphane Payrard]

Le Sat, Apr 10, 2004 at 08:33:04PM +0100, le valeureux mongueur Alberto Manuel Brandao Simoes a dit:

Same probleme here on Mandrake 9.2. Some more information if that helps:

gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.3.1/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java,pascal --host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)

Linux stefp.dyndns.org 2.4.22-6mdk #1 Sun Sep 7 18:11:19 EDT 2003 i686 unknown unknown GNU/Linux

>
> Cheers
> Alberto

[Jeff Clites]

It's odd, but try this:

1) cd into icu/source/data

2) Edit the Makefile. Look for this:

$(BUILDDIR)/$(ICUDT)%.res: $(INDEX_FILES)
$(TOOLDIR)/genrb/genrb$(EXEEXT)
ICU_DATA=$(BUILDDIR) $(INVOKE) $(TOOLDIR)/genrb/genrb
$(GENRBOPTS) -p $(ICUDATA_PLATFORM_NAME) -d $(BUILDDIR) $(INDEX_FILES)

Add this: -i $(BUILDDIR)
right before: -d $(BUILDDIR)

so that you have:

$(BUILDDIR)/$(ICUDT)%.res: $(INDEX_FILES)
$(TOOLDIR)/genrb/genrb$(EXEEXT)
ICU_DATA=$(BUILDDIR) $(INVOKE) $(TOOLDIR)/genrb/genrb
$(GENRBOPTS) -p $(ICUDATA_PLATFORM_NAME) -i $(BUILDDIR) -d $(BUILDDIR)
$(INDEX_FILES)

3) While in same directory, execute:

make ENABLE_STATIC=

(yes, there's nothing to the right of the "=".)

If that succeeds, then we need to patch icu/source/data/Makefile.in to
add that. If it still fails, try one more thing: add a slash, so that
you have:

-i $(BUILDDIR)/

instead of:

-i $(BUILDDIR)

and then try the "make ENABLE_STATIC=" again.

If it's still failing, then something else is going on.

If it is, then there's one more thing to try:

1) cd into icu/source/data/out/build

2) Execute this (which will create ja.res in /var/tmp if it succeeds):

../../../tools/genrb/genrb -k -s ../../locales -i . -d /var/tmp ja.txt

If that succeeds, then the above should have also works. If it fails,
then send me the message it outputs, which should be similar to your
above-reported output, but with a little additional diagnostic
information.

Thanks,

JEff

[Alberto Manuel Brandao Simoes]

Here it goes...

> It's odd, but try this:
>
> 1) cd into icu/source/data
>
> 2) Edit the Makefile. Look for this:
>
> $(BUILDDIR)/$(ICUDT)%.res: $(INDEX_FILES) $(TOOLDIR)/genrb/genrb$(EXEEXT)
> ICU_DATA=$(BUILDDIR) $(INVOKE) $(TOOLDIR)/genrb/genrb
> $(GENRBOPTS) -p $(ICUDATA_PLATFORM_NAME) -d $(BUILDDIR) $(INDEX_FILES)
>
> Add this: -i $(BUILDDIR)
> right before: -d $(BUILDDIR)
>
> so that you have:
>
> $(BUILDDIR)/$(ICUDT)%.res: $(INDEX_FILES) $(TOOLDIR)/genrb/genrb$(EXEEXT)
> ICU_DATA=$(BUILDDIR) $(INVOKE) $(TOOLDIR)/genrb/genrb
> $(GENRBOPTS) -p $(ICUDATA_PLATFORM_NAME) -i $(BUILDDIR) -d $(BUILDDIR)
> $(INDEX_FILES)
>
> 3) While in same directory, execute:
>
> make ENABLE_STATIC=

Samething:

[ambs@holst data]$ make ENABLE_STATIC=
/bin/sh ../mkinstalldirs ../data/out ../data/out/build
../test/testdata/out ../test/testdata/out/build
ICU_DATA=../data/out/build
LD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../stubdata/:$LD_LIBRARY_PATH
../tools/genrb/genrb -k -q -p icudt26l -s ../data/locales -d
../data/out/build ja.txt

../data/locales/ja.txt:15: parse error. Stopped parsing with
U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR

make: *** [../data/out/build/icudt26l_ja.res] Error 3

>
> If that succeeds, then we need to patch icu/source/data/Makefile.in to
> add that. If it still fails, try one more thing: add a slash, so that
> you have:
>
> -i $(BUILDDIR)/
>
> instead of:
>
> -i $(BUILDDIR)
>
> and then try the "make ENABLE_STATIC=" again.

Samething.

> If it's still failing, then something else is going on.
>
> If it is, then there's one more thing to try:
>
> 1) cd into icu/source/data/out/build
>
> 2) Execute this (which will create ja.res in /var/tmp if it succeeds):
>
> ../../../tools/genrb/genrb -k -s ../../locales -i . -d /var/tmp ja.txt
>
> If that succeeds, then the above should have also works. If it fails,
> then send me the message it outputs, which should be similar to your
> above-reported output, but with a little additional diagnostic information.

Yes, fails!

[ambs@holst build]$ ../../../tools/genrb/genrb -k -s ../../locales -i .
-d /var/tmp ja.txt
../../locales/ja.txt:17: warning: %Collation could not be constructed
from CollationElements - check context!
../../locales/ja.txt:15: parse error. Stopped parsing with

U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR

Cheers :-)
Alberto

[Jeff Clites]

On Apr 11, 2004, at 7:12 AM, Alberto Manuel Brandao Simoes wrote:

>> If it's still failing, then something else is going on.
>> If it is, then there's one more thing to try:
>> 1) cd into icu/source/data/out/build
>> 2) Execute this (which will create ja.res in /var/tmp if it succeeds):
>> ../../../tools/genrb/genrb -k -s ../../locales -i . -d /var/tmp ja.txt
>> If that succeeds, then the above should have also works. If it fails,
>> then send me the message it outputs, which should be similar to your
>> above-reported output, but with a little additional diagnostic
>> information.
>
> Yes, fails!
>
> [ambs@holst build]$ ../../../tools/genrb/genrb -k -s ../../locales -i
> . -d /var/tmp ja.txt
> ../../locales/ja.txt:17: warning: %Collation could not be constructed
> from CollationElements - check context!
> ../../locales/ja.txt:15: parse error. Stopped parsing with
> U_INVALID_FORMAT_ERROR
> couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR

Hmm, strange indeed. Looking at the ICU code, it appears that it's not
finding a data file it needs at this stage (the error message is
misleading)--I wonder if something failed to create it, but 'make'
continued on?

What ".icu" files are in that directory (icu/source/data/out/build) for
you? I have these (and I'd expect you'd have "l" rather than "b" in
your prefix [little v. big endian]):

% ls *.icu
icudt26b_cnvalias.icu icudt26b_tz.icu icudt26b_unames.icu
icudt26b_invuca.icu icudt26b_ucadata.icu icudt26b_unorm.icu
icudt26b_pnames.icu icudt26b_uidna.icu icudt26b_uprops.icu

I believe it's the "*_ucadata.icu" that it's failing to find.

So if that file's missing for you, we need to look for an earlier
failure in the build. If it's there, then we can do some gdb
investigating. Starting from the same directory as before:

% gdb ../../../tools/genrb/genrb

(gdb) b udata_pathiter_init

(gdb) r -k -s ../../locales -i . -d /var/tmp ja.txt

Breakpoint 1, udata_pathiter_init (iter=0xbfffe3d0, path=0x900140 ".",
item=0xcdf68 "icudt26b", suffix=0xbfffebf8 "_cnvalias.icu",
doCheckLastFour=0 '\0') at udata.c:357
357 if(path == NULL) {
(gdb) c
Continuing.

Breakpoint 1, udata_pathiter_init (iter=0xbfffdb80, path=0x900140 ".",
item=0xcdf68 "icudt26b", suffix=0xbfffe3a8 "_ucadata.icu",
doCheckLastFour=0 '\0') at udata.c:357
357 if(path == NULL) {

The second time you hit the breakpoint should be the one we are
interested in--the "item" and "suffix" parameters should concatenate to
that file name from above, and "path" is where it's going to look for
the file. So if the file is there, and that path is correct, then it
must be failing somewhere else, so I'll be back to being confused.

JEff

[Alberto Manuel Brandao Simoes]

Some more info...

same files, with l instead of b, as expected.

> I believe it's the "*_ucadata.icu" that it's failing to find.
>
> So if that file's missing for you, we need to look for an earlier
> failure in the build. If it's there, then we can do some gdb
> investigating. Starting from the same directory as before:

It is there.
>
> % gdb ../../../tools/genrb/genrb

Here the breakpoints go. I pointed with >>> <<< some weird poitns...

Breakpoint 1, udata_pathiter_init (iter=0xbfffde78, path=0x814a050 ".",
item=0x811bbc8 "cnvalias", suffix=0xbfffde78 "_cnvalias.icu",

doCheckLastFour=0 '\0') at udata.c:357
357 if(path == NULL) {
(gdb) c
Continuing.

Breakpoint 1, udata_pathiter_init (iter=0xbfffd658, path=0x814a050 ".",
item=0x8112f3a "ucadata", suffix=0xbfffd658 "_ucadata.icu",

doCheckLastFour=0 '\0') at udata.c:357
357 if(path == NULL) {

(gdb) c
Continuing.

Breakpoint 1, udata_pathiter_init (iter=0xbfffc7f8, path=0x814a050 ".",
item=0x811ff40 "uprops", suffix=0xbfffc7f8 "_uprops.icu",

doCheckLastFour=0 '\0') at udata.c:357
357 if(path == NULL) {
(gdb) c
Continuing.

Breakpoint 1, udata_pathiter_init (iter=0xbfffd568, path=0x814a050 ".",
item=0x811fc03 "unorm", suffix=0xbfffd568 "_unorm.icu",
doCheckLastFour= >>>>-65 '¿'<<<<) at udata.c:357

357 if(path == NULL) {
(gdb) c
Continuing.

Breakpoint 1, udata_pathiter_init (iter=0xbfffd618, path=0x814a050 ".",
item=0x81135f0 "invuca", suffix=0xbfffd618 "_invuca.icu",
doCheckLastFour=>>>>-65 '¿'<<<<) at udata.c:357

357 if(path == NULL) {
(gdb) c
Continuing.

../../locales/ja.txt:17: warning: %Collation could not be constructed
from CollationElements - check context!
../../locales/ja.txt:15: parse error. Stopped parsing with
U_INVALID_FORMAT_ERROR
couldn't parse the file ja.txt. Error:U_INVALID_FORMAT_ERROR

Program exited with code 03.
(gdb)

Cheers

[Jeff Clites]

On Apr 11, 2004, at 12:38 PM, Alberto Manuel Brandao Simoes wrote:

> Some more info...

Thanks!

> Jeff Clites wrote:
>>

Hmm, that "item" should be set to "icudt26l", not "ucadata". But, since
ICU is building optimized, it's possible that it will be set to the
right thing by the time it's used. It looks like that value should be
coming from a chain of #defines, so I think this may be the debugger
misleading us, since it shouldn't be able to change between calls to
udata_pathiter_init (at least, I think).

But, here's another idea: It looks like ultimately the file is getting
memory-mapped, so maybe there's a problem there. It also looks like
there are different implementations for different platforms, so maybe
you're getting into the wrong one somehow. So, try breaking on
"uprv_mapFile_2_6", or on "udata.c:977", and step into that function.
The second time you hit it, it should look similar to this, with
s/b/l/:

#0 uprv_mapFile_2_6 (pData=0xbfffe880, path=0xbfffdf94
"./icudt26b_ucadata.icu") at umapfile.c:175

If that path looks wrong, we need to look before this for where it
built that string. If it's okay, then keep stepping and see if the
stat() works, or if/where it finally fails. This will also tell us
which implementation of the uprv_mapFile you are getting.

Also, check what U_HAVE_MMAP is being #define'd to in
icu/source/common/unicode/platform.h. If it's 0, then try setting it to
1 and issuing "make" in the icu/source directory. This might all be a
config error, sending you into code which has a bug but shouldn't be
hit anyway.

Thanks for the debugging help! (It's a low-tech remote debugger.)

JEff

[Alberto Manuel Brandao Simoes]

Jeff,
I am a little lost in that code as you might imagine :-)

BTW, the HAVE_MMAP is defined.

I set a breakpoint at "uprv_mapFile_2_6", and here is some of the gdb
debug...

[New Thread 16384 (LWP 942)]
[Switching to Thread 16384 (LWP 942)]

Breakpoint 1, uprv_mapFile_2_6 (pData=0xbfffd9e0,
path=0xbfffe2f4 "./icudt26l_cnvalias.icu") at umapfile.c:165
165 UDataMemory_init(pData); /* Clear the output struct.
*/
(gdb) c
Continuing.

Breakpoint 1, uprv_mapFile_2_6 (pData=0xbfffd1c0,
path=0xbfffdad4 "./icudt26l_ucadata.icu") at umapfile.c:165
165 UDataMemory_init(pData); /* Clear the output struct.
*/
(gdb) s
159 uprv_mapFile(UDataMemory *pData, const char *path) {
(gdb) s
165 UDataMemory_init(pData); /* Clear the output struct.
*/
(gdb) s
UDataMemory_init_2_6 (This=0xbfffd1b8) at udatamem.c:27
27 uprv_memset(This, 0, sizeof(UDataMemory));
(gdb) s
26 void UDataMemory_init(UDataMemory *This) {
(gdb) s
27 uprv_memset(This, 0, sizeof(UDataMemory));
(gdb) s
26 void UDataMemory_init(UDataMemory *This) {
(gdb) s
27 uprv_memset(This, 0, sizeof(UDataMemory));
(gdb) s
28 }
(gdb) s
uprv_mapFile_2_6 (pData=0xbfffd1c0, path=0xbfffdad4
"./icudt26l_ucadata.icu")
at stat.h:358
358 {
(gdb) s
359 return __xstat (_STAT_VER, __path, __statbuf);
(gdb) s
358 {
(gdb) s
174 fd=open(path, O_RDONLY);
(gdb) s
175 if(fd==-1) {
(gdb) s
181 data=mmap(0, length, PROT_READ, MAP_SHARED, fd, 0);
(gdb) s
185 close(fd); /* no longer needed */
(gdb) s
181 data=mmap(0, length, PROT_READ, MAP_SHARED, fd, 0);
(gdb) s
185 close(fd); /* no longer needed */

^^^^^^^^^^^^^^^^^^^^ I DONT LIKE THIS but maybe is just me :-)
shouldn't we have an open fd again, or that close should be there? :)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(gdb) s
186 if(data==MAP_FAILED) {
(gdb)
190 pData->map = (char *)data + length;
(gdb)
191 pData->pHeader=(const DataHeader *)data;
(gdb)

[Jeff Clites]

On Apr 11, 2004, at 1:54 PM, Alberto Manuel Brandao Simoes wrote:

> Jeff,
> I am a little lost in that code as you might imagine :-)

I am a bit as well--I basically went looking for the error message, and
have been trying to figure out where in the code the error is actually
originating.

> Breakpoint 1, uprv_mapFile_2_6 (pData=0xbfffd1c0,
> path=0xbfffdad4 "./icudt26l_ucadata.icu") at umapfile.c:165

Good, it looks like the path is right.

> 165 UDataMemory_init(pData); /* Clear the output struct.
> */
> (gdb) s
> 159 uprv_mapFile(UDataMemory *pData, const char *path) {
> (gdb) s
> 165 UDataMemory_init(pData); /* Clear the output struct.
> */
> (gdb) s

...

> 174 fd=open(path, O_RDONLY);
> (gdb) s
> 175 if(fd==-1) {
> (gdb) s
> 181 data=mmap(0, length, PROT_READ, MAP_SHARED, fd, 0);
> (gdb) s
> 185 close(fd); /* no longer needed */
> (gdb) s
> 181 data=mmap(0, length, PROT_READ, MAP_SHARED, fd, 0);
> (gdb) s
> 185 close(fd); /* no longer needed */
>
> ^^^^^^^^^^^^^^^^^^^^ I DONT LIKE THIS but maybe is just me :-)
> shouldn't we have an open fd again, or that close should be there? :)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It's probably okay. It's alright to close the fd after the mmap, and
it's not really calling mmap twice--it's just the debugger trying to
follow the optimized code.

Hmm, so it's looking like the error message may be genuine, in that the
problem it's having is with ja.txt, and not a problem finding some
other file. So maybe we should check the obvious, and see if that file
got corrupted for you:

% cksum ./icu/source/data/locales/ja.txt
1401130956 170397 ./icu/source/data/locales/ja.txt
% md5 ./icu/source/data/locales/ja.txt
MD5 (./icu/source/data/locales/ja.txt) =
728d7bb46a270b2d8ec07e96527858d7

Do those match?

When I build, ja.txt isn't the first locale it gets to--I have lines
like this right before it, invoking the same tool:

ICU_DATA=../data/out/build
DYLD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../
layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../
stubdata/:$DYLD_LIBRARY_PATH ../tools/genrb/genrb -k -q -p icudt26b -s
../data/locales -d ../data/out/build it_IT.txt
ICU_DATA=../data/out/build
DYLD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../
layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../
stubdata/:$DYLD_LIBRARY_PATH ../tools/genrb/genrb -k -q -p icudt26b -s
../data/locales -d ../data/out/build it_IT_PREEURO.txt

If you do too, then that implies that it may be something specific to
ja.txt, rather than a general problem with genrb doing it's thing.

One other thing to do, if ja.txt looks okay:

Break on "parse.c:665", then "next" until you get to where it prints
the warning, and see what "intStatus" and "coll" are set to. Then,
start over, but step into the call to ucol_openRules, and see if you
can tell where the error is getting set (assuming you found intStatus
set to some error code)--so far I've been guessing wrong. (I can
re-create the same error if I don't add the "-i" flag when running by
hand, but maybe the cause in your case is something completely
different--for me, that make it unable to locate the data file.)

JEff

[Alberto Manuel Brandao Simoes]

Here we go,

>
> It's probably okay. It's alright to close the fd after the mmap, and
> it's not really calling mmap twice--it's just the debugger trying to
> follow the optimized code.

OK, Just my ignorance :-)

>
> Hmm, so it's looking like the error message may be genuine, in that the
> problem it's having is with ja.txt, and not a problem finding some
> other file. So maybe we should check the obvious, and see if that file
> got corrupted for you:
>
> % cksum ./icu/source/data/locales/ja.txt
> 1401130956 170397 ./icu/source/data/locales/ja.txt

1401130956 170397 ./icu/source/data/locales/ja.txt (aligns)

> % md5 ./icu/source/data/locales/ja.txt
> MD5 (./icu/source/data/locales/ja.txt) = 728d7bb46a270b2d8ec07e96527858d7

728d7bb46a270b2d8ec07e96527858d7 (aligns)

> Do those match?
Yep :-|

>
> When I build, ja.txt isn't the first locale it gets to--I have lines
> like this right before it, invoking the same tool:
>
> ICU_DATA=../data/out/build
> DYLD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../
> layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../
> stubdata/:$DYLD_LIBRARY_PATH ../tools/genrb/genrb -k -q -p icudt26b -s
> ../data/locales -d ../data/out/build it_IT.txt
> ICU_DATA=../data/out/build
> DYLD_LIBRARY_PATH=../common:../i18n:../tools/toolutil:../layout:../
> layoutex:../extra/ustdio:../tools/ctestfw:../data/out:../data:../
> stubdata/:$DYLD_LIBRARY_PATH ../tools/genrb/genrb -k -q -p icudt26b -s
> ../data/locales -d ../data/out/build it_IT_PREEURO.txt
>
> If you do too, then that implies that it may be something specific to
> ja.txt, rather than a general problem with genrb doing it's thing.

Yep. Other locales seem to work correctly.

>
> One other thing to do, if ja.txt looks okay:
>
> Break on "parse.c:665", then "next" until you get to where it prints
> the warning, and see what "intStatus" and "coll" are set to.

Breakpoint 1, parseCollationElements (tag=0x814b6b8 "", startline=15,
status=0xbfffef38) at parse.c:665
665 coll = ucol_openRules(member->u.fString.fChars,
member->u.fString.fLength,
(gdb) next
655 UErrorCode intStatus = U_ZERO_ERROR;
(gdb) next
658 int32_t len = 0;
(gdb)
665 coll = ucol_openRules(member->u.fString.fChars,
member->u.fString.fLength,
(gdb)
668 if (U_SUCCESS(intStatus) && coll != NULL)
(gdb)
701 warning(line, "%%Collation could not be
constructed from CollationElements - check context!");
(gdb) p coll
$1 = (UCollator *) 0x0
(gdb) p intStatus
$2 = U_INTERNAL_PROGRAM_ERROR
(gdb)

> Then,
> start over, but step into the call to ucol_openRules, and see if you
> can tell where the error is getting set (assuming you found intStatus
> set to some error code)

At the moment I can't help much here.

Cheers
Alberto

[Jeff Clites]

On Apr 11, 2004, at 3:15 PM, Alberto Manuel Brandao Simoes wrote:

> Here we go,
>> It's probably okay. It's alright to close the fd after the mmap, and
>> it's not really calling mmap twice--it's just the debugger trying to
>> follow the optimized code.
>
> OK, Just my ignorance :-)

Nope--normally one tries to avoid debugging something built with
optimizations turned on, but here we are!

> Breakpoint 1, parseCollationElements (tag=0x814b6b8 "", startline=15,
> status=0xbfffef38) at parse.c:665
> 665 coll =
> ucol_openRules(member->u.fString.fChars, member->u.fString.fLength,
> (gdb) next
> 655 UErrorCode intStatus = U_ZERO_ERROR;
> (gdb) next
> 658 int32_t len = 0;
> (gdb)
> 665 coll =
> ucol_openRules(member->u.fString.fChars, member->u.fString.fLength,
> (gdb)
> 668 if (U_SUCCESS(intStatus) && coll != NULL)
> (gdb)
> 701 warning(line, "%%Collation could not be
> constructed from CollationElements - check context!");
> (gdb) p coll
> $1 = (UCollator *) 0x0
> (gdb) p intStatus
> $2 = U_INTERNAL_PROGRAM_ERROR

Here's another way to maybe track it down: Once you get to your
breakpoint do "watch intStatus", and then continue until you see it
being set to U_INTERNAL_PROGRAM_ERROR, and get a backtrace. But, I
think it will probably just get set by copying it over from another
result code somewhere, and so it might require doing that with a few
other variable to really track it down. But, it's sounding more like
something is just generally messed up.

Thanks again for the help.

JEff

[Dan Sugalski]

FWIW, taking a look at the Debian-specific ICU patches for their
testing branch might be worthwhile. They've patched the thing up to
get it to build, and since it's the only system I have locally that
*doesn't* build ICU, I suspect there's something either Debian-ish
going wrong, or more Linux in general.

I'll try and get patches to use the system ICU install if there is
one done today.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Jeff Clites]

On Apr 12, 2004, at 6:37 AM, Dan Sugalski wrote:

> I'll try and get patches to use the system ICU install if there is one
> done today.

Also take a look at my [perl #28473], which I don't think has made it
to the list yet. That's a patch to make the location of ICU's data
directory configurable, so it should help with that.

JEff