Re: building moz m117

Here's a hint.
I deliberately left the install mode in Unix. I guess that means I'm in 
binary mode. Yes?

I'll mess with cygcheck in the morning.
Thanks
Jack

Volker Quetschke wrote:

> Hi!
> 
>> "textmounts". I just googled that. First time I ever heard
>> of it (you're forcing me to reveal just how ignorant I
>> really am ;)
> 
> 
> Hmm, can you attach the cygcheck.log generated with:
> $ cygcheck -svr > cygcheck.log
> 
> Then we can see what you're using.
> 
>> Even google didn't help. I have no idea if I'm "using
>> cygwin textmounts."  I just ran the installer yesterday and
>> upgraded cygwin to the latest spec. I'm just a naive user.
>>
>> Like you, I remain curious why it is that just removing
>> some tabbed line empty lines got me further.
>>
>> I also remain curous why it is that there were calls for
>> some GB language packs in the US directory in one of the
>> make files (something I mentioned in an earlier post).
>>
>> I also remain aware that cygwin seems somewhat grumpy. If I
>> do things like open, say, a pdf file, cygwin might crash.
>> If I restart (after rebooting the entire computer), it
>> catches up and goes beyond the crash. That happened twice
>> today.  Knock on wood, it's still compiling now.
> 
> That doesn't look good. Let me assure you that cygwin runs
> completely in "user mode"[1] and is not executing code on system
> level, therefore it cannot interfere with other windows
> programs that are not cygwin based.
> 
> If your system crashes when opening a pdf file (with Adobe
> Acrobat I assume?) you're in serious trouble. Did you check
> for viruses/trojans lately?
> 
> Even if your system crashes when using cygwin's xpdf when
> viewing your pdf file I would be concered because even that
> should work flawlessly.
> 
>> If I get a brief tutorial on how to see if I'm using cygwin
>> textmounts (and how to change that if I am), I'll be able
>> to answer your question.
> 
> <http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html#ov-hi-textvsbinary>
> Post the cygcheck.log and we see what you choose when installing
> cygwin. The build instructions say:
>  > When installing Cygwin make sure you set the "Default Text File Type"
>  > to "Unix". This is the default setting.
> This leads to binary mode mounts.
> 
> Volker
> 
> [1] This doesn't mean that cygwin programs cannot crash, but the cygwin
> dll is only loaded when a program is compiled to use it and "normal"
> programs don't do this. Cygwin doesn't sneak into your system and hooks
> into system functions like McAffee and friends. To me it appears to be
> really stable. (with the exeception of the mentioned timing problem in
> 1.5.18)
> 
> 
>>
>> On Tue, 19 Jul 2005 17:44:26 -0400
>>  Volker Quetschke <[email protected]> wrote:
>>
>>> [email protected] wrote:
>>>
>>>> Well, I have to say that this advice worked! Thank you
>>>
>>>
>>> very
>>>
>>>> much.  As I type this, compiling is still running, well
>>>> past where it ended before.
>>>
>>>
>>> Wait a second! Why is it necessary? It works well for me
>>> and
>>> propably also for Pavel, as he is still providing
>>> milestone
>>> snapshots.
>>>
>>>
>>>> What I did:  I opened the file in textpad and removed
>>>
>>>
>>> all
>>>
>>>> blank lines. I noted that some blank lines had tabs in
>>>> them. When I saved that file and restarted dmake, it
>>>> breezed past that area and is still compiling.
>>>
>>>
>>> Something is *MEGA*fishy here.
>>>
>>> Jack, are you using cygwin textmounts?
>>>
>>> If yes, I'm surprised that you got that far.
>>>
>>>
>>>
>>>> Many thanks for this advice.
>>>
>>>
>>> Well, this might solve this problem for you, but I'm still
>>> wondering why only you are having these problems.
>>>
>>> Volker
>>>
>>>
>>>
>>>> Best regards,
>>>> Jack
>>>>
>>>> On Tue, 19 Jul 2005 14:37:52 +0200
>>>> Hans-Joachim Lankenau <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>>> hi!
>>>>>
>>>>> right, there were several issues in the past with empty
>>>>> lines inside rule/target definition. IIRC, sometimes
>>>>> related to lineend conventions. also new (not yet in the
>>>>> MWS) versions seem to be able to handle this correct.
>>>>>
>>>>> this error exactly looks like.
>>>>>
>>>>> anyway, i would suggest removing the empty lines inside
>>>>> the targets of "moz/extractfiles.mk".
>>>>>
>>>>> note that a new checkout of "solenv" won't help at all.
>>>>>
>>>>> tschau...
>>>>>
>>>>> ause
>>>>>
>>>>> Joerg Barfurth wrote:
>>>>>
>>>>>
>>>>>> Hi Jack,
>>>>>>
>>>>>> [email protected] wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Well, that ought to teach me to comment stuff out.
>>>
>>>
>>> Now,
>>>
>>>>> it
>>>>>
>>>>>
>>>>>>> crashes in the very next block of code with this
>>>
>>>
>>> error:
>>>
>>>>>>> /cygdrive/c/downloads/openOffice/src680_m117/moz
>>>>>>> dmake:  extractfiles.mk:  line 240:  Error --
>>>
>>>
>>> Expecting
>>>
>>>>>>> macro or rule defn, foun
>>>>>>> d neither
>>>>>>>
>>>>>>
>>>>>> Looking at that error and your previous one gives an
>>>>>
>>>>>
>>>>> idea of the
>>>>>
>>>>>
>>>>>> problem. It probably was caused by cvs (maybe the
>>>>>
>>>>>
>>>>> version you are using
>>>>>
>>>>>
>>>>>> or some option ?).
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The code it's crashing in now is this:
>>>>>>>
>>>>>>> # copy files in COMPONENT_RUNTIMELIST
>>>>>>>   +$(foreach,file,$(COMPONENT_RUNTIMELIST) $(COPY)
>>>>>>> $(MOZ_BIN_DIR)$/components$/$(DLLPRE)$(file)$(DLLPOST)
>>>>>
>>>>>
>>>>> \
>>>>>
>>>>>
>>>
>>> $(RUNTIME_DIR)$/components$/$(DLLPRE)$(file)$(DLLPOST)
>>>
>>>>> &&)
>>>>>
>>>>>
>>>>>>> \
>>>>>>>   echo >& $(NULLDEV)
>>>>>>>
>>>>>>
>>>>>> The contents of this is irrelevant. This code is
>>>>>
>>>>>
>>>>> supposed to be part of
>>>>>
>>>>>
>>>>>> a rule definition (the
>>>>>
>>>>>
>>>>> $(MISC)$/build$/so_moz_runtime_files one).
>>>>>
>>>>>
>>>>>> Apparently dmake does not reckognize that this piece of
>>>>>
>>>>>
>>>>> code (and
>>>>>
>>>>>
>>>>>> earlier the @echo in the non-Solaris case) is still
>>>
>>>
>>> part
>>>
>>>>> of that rule,
>>>>>
>>>>>
>>>>>> due to the blank-looking lines that separate the
>>>
>>>
>>> blocks.
>>>
>>>>>> IIRC these lines must not be empty, but should contain
>>>
>>>
>>> a
>>>
>>>>> 'tab' character
>>>>>
>>>>>
>>>>>> at the beginning that signals to dmake that they are
>>>>>
>>>>>
>>>>> still part of the
>>>>>
>>>>>
>>>>>> rule. Either cvs or an oversmart text editor apparently
>>>>>
>>>>>
>>>>> has stripped
>>>>>
>>>>>
>>>>>> this tab in the line before '# copy files in
>>>>>
>>>>>
>>>>> RES_FILELIST' (possibly in
>>>>>
>>>>>
>>>>>> more).
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Now, I have to wonder if it's not unzipping the files
>>>>>
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>>>> the /moz/zipped directory.
>>>>>>>
>>>>>>> In short, something is not right, and commenting out
>>>>>
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>> effects of testing for solaris didn't fix anything.
>>>>>>>
>>>>>>> More research. Maybe this new "bug" will trigger some
>>>>>
>>>>>
>>>>> more
>>>>>
>>>>>
>>>>>>> ideas.
>>>>>>>
>>>>>>
>>>>>> Maybe a fresh checkout of solenv is the most promising
>>>>>
>>>>>
>>>>> idea to fix this.
>>>>>
>>>>>
>>>>>> HTH, Joerg
>>>>>>