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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
