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
