75223 - NSPRPUB configure crashes when run in Win2K term window

Status: VERIFIED INVALID

(SeaMonkey :: Build Config, defect)

Description

[Curtis Clauson]

The Win32 build crashes when run on a Win2KPro OS with MSVC6 during the
following circumstances.
   * The environment variables CC_FOR_BUILD, HOST_CC, and CC are NOT defined.
   * The build_nspr target is executed in client.mak (say through a
pull_and_build_all target)
   * gmake will run $(MOZ_SRC)/nsprpub/gmakefile.win
   * $(MOZ_OBJDIR)/config.status is missing or out of date
   * The $(MOZ_OBJDIR) directory will be removed
   * A new $(MOZ_OBJDIR) directory is created
   * The current directory is changed to $(MOZ_OBJDIR) and "sh ../configure
<parameters>" is run
   * configure calls "sh ../build/autoconf/config.guess" which echoes a
machine/system ID string

However, the config.guess shell script is no longer correctly reporting the
machine/system ID string. On my Pentium II Win2KPro machine I should get
   i686-pc-cygwin

Instead I'm getting
   dummy-2040.rel does not exist
   i686-pc-cygwin

This then causes a cascade of errors in configure which ends up creating an
empty makefile in $(MOZ_SRC)/nsprpub/$(MOZ_OBJDIR), which causes the build of
nspr to fail.

The cause of the problem is the fact that the cygwin commands are being run in a
Windows terminal window. Some cygwin commands display more output in a Windows
terminal window than in a Cygwin terminal window. The specific problem here is
with the "rm -f" command. If this command is done in a Cygwin terminal window
and the file to be deleted does not exist, nothing is displayed. But in a
Windows terminal window the line "<filename> does not exist" is displayed to stdout.

In $(MOZ_SRC)/nsprpub/build/autoconf/config.guess line 98, the script uses some
default names for a C compiler to compile a dummy C file in order to identify
the resident C compiler and assign its name to CC_FOR_BUILD. Line 106 removes
the created test files with the following line:
   rm -f $dummy.c $dummy.o $dummy.rel

This is what is causing the problem. In the previous version of this file the
line was:
   rm -f $dummy.c $dummy.o

This worked just fine in a Windows terminal window since both $dummy.c and
$dummy.o existed to be deleted. With the new version during a Win32 build with
MSVC6, the file $dummy.rel is never created. The rm command for the current
version deletes the $dummy.c and $dummy.o files, but will display
"dummy-<number>.rel does not exist" when run in a Windows terminal window. After
that the rest of the script executes as normal and displays the normal
machine/system ID string.

This line, and any other rm command line that uses "-f" where the file to be
deleted might not exist, MUST have " > /dev/null" appended to the end to keep
the extra message from displaying when run in a Windows terminal window. Line
106 of the config.guess file should be:
   rm -f $dummy.c $dummy.o $dummy.rel > /dev/null

Making this change then allows the windows build to execute correctly on my
Win2KPro machine. But there may be other places where this same kind of problem
is just waiting for the right script change to bring it out. The entire nspr
autoconfigure script suite needs to be rechecked for this problem of extra
display text when run in a Windows terminal window that may interfere with
proper execution.

A workaround to this is to add a definition for the CC environment variable to
the environment variable section of the Win32 build instructions
(http://www.mozilla.org/build/win32.html#ss2.2). It solves this specific problem
but does not address the other problems that may crop up because of the extra
displayed text.

It would also help if this undocumented boiler-plated monstrosity we call the
Mozilla build environment were actually documented out so that we didn't need to
burn 6 hours trying to debug something that should never have passed through
testing to begin with.

This bug was introduced as a result of the work done to fix
http://bugzilla.mozilla.org/show_bug.cgi?id=58804.

Comment 1

[Curtis Clauson]

Attachment: Bad nspr confugure output in a Windows terminal window.

Comment 2

[Curtis Clauson]

Attachment: Good nspr configure output in a Windows terminal window.

Comment 3

[Curtis Clauson]

Attachment: Output of the failed attempt to build with "build_all"

Comment 4

[cls]

Works fine in my W2k build, so on with the standard questions:

Which version of cygwin to you have installed?
What shell is sh?
Which version of fileutils do you have installed? (This package contains rm)
What does running cygcheck on the following bins return: sh rm ash bash

Comment 5

[Curtis Clauson]

<extreme sigh> Ya know, I spent all night thrashing this out because this
undocumented build architecture has stood in my way of understanding this
package too many times before, and now it turns out that the problem was elsewhere.

Microsoft installations have been mucking around with my paths again. There is
another version of rm.exe in the MS Platform SDK whose path has been quietly
prepended to my path. It was being run instead of the cygwin rm command. It
worked on the past versions only because the rm command always designated files
that existed.

Cygwin 1.1.8
sh.exe from cygwin/bin/sh.exe
fileutils-4.0-3.tar.gz
cygcheck found 
   one of sh.exe and bash.exe in cygwin/bin
   two rm.exe, one in cygwin/bin and one in MSPSDK/bin
   no ash.exe - The ash package only contains sh.exe

I am not the only one who has run into this problem. Check newsgroup
n.p.m.builds: "Error building on Windows 2000". I've corrected my response. It
would help though if mention of the cygcheck utility were made in the Win32
build page to show the user if they've got multiple versions or not. Anyway,
thanks for the heads-up.

This bug doesn't exist. Expunge it. I'm going to bed. <grumble, grumble, grumbling>.

Comment 6

[cls]

Marking invalid per reporter's comments.

Comment 7

[Jon Granrose]

verified.