Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <jcli...@mac.com>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 92635 invoked by uid 76); 11 Apr 2004 21:57:57 -0000
Received: from x1.develooper.com (HELO x1.develooper.com) (63.251.223.170)
  by onion.perl.org (qpsmtpd/0.27.1) with SMTP; Sun, 11 Apr 2004 14:57:57 -0700
Received: (qmail 24424 invoked by uid 225); 11 Apr 2004 21:57:54 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 24420 invoked by alias); 11 Apr 2004 21:57:53 -0000
X-Spam-Status: No, hits=0.0 required=7.0
	tests=
X-Spam-Check-By: la.mx.develooper.com
Received: from A17-250-248-97.apple.com (HELO smtpout.mac.com) (17.250.248.97)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Sun, 11 Apr 2004 14:57:52 -0700
Received: from mac.com (smtpin08-en2 [10.13.10.153])
	by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i3BLvmtA028637;
	Sun, 11 Apr 2004 14:57:48 -0700 (PDT)
Received: from [192.168.0.60] (adsl-209-204-178-23.sonic.net [209.204.178.23])
	(authenticated bits=0)
	by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i3BLvkBP014140;
	Sun, 11 Apr 2004 14:57:47 -0700 (PDT)
In-Reply-To: <4079B06C.4050307@alfarrabio.di.uminho.pt>
References: <40784BF0.20608@alfarrabio.di.uminho.pt> <2D6A80E0-8B49-11D8-ADF3-000393A6B9DA@mac.com> <40795254.9080604@alfarrabio.di.uminho.pt> <4E585890-8BEE-11D8-ADF3-000393A6B9DA@mac.com> <40799EA7.4080507@alfarrabio.di.uminho.pt> <CDC9D729-8BF6-11D8-ADF3-000393A6B9DA@mac.com> <4079B06C.4050307@alfarrabio.di.uminho.pt>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <437D9AB0-8C03-11D8-ADF3-000393A6B9DA@mac.com>
Content-Transfer-Encoding: 7bit
Cc: perl6-intern...@perl.org
Subject: Re: Build problems in i386 linux
Date: Sun, 11 Apr 2004 14:57:45 -0700
To: Alberto Manuel Brandao Simoes <al...@alfarrabio.di.uminho.pt>
X-Mailer: Apple Mail (2.609)
Approved: n...@nntp.perl.org
From: jcli...@mac.com (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