Re: [tools-dev] building moz m117

Volker Quetschke Tue, 19 Jul 2005 20:15:55 -0700

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

'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]

---------------------------------------------------------------------

To unsubscribe, e-mail:


[EMAIL PROTECTED]

For additional commands, e-mail:


[EMAIL PROTECTED]


--
If you like my work consider:
http://www.scytek.de/donations.html
PGP/GPG key  (ID: 0x9F8A785D)  available  from
wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA
9F8A 785D




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
If you like my work consider:  http://www.scytek.de/donations.html
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D

signature.asc
Description: OpenPGP digital signature

Re: [tools-dev] building moz m117

Reply via email to