If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

configure fails on NT



15 years ago
15 years ago


(Reporter: Sonja Mirtitsch, Assigned: Wan-Teh Chang)


Windows NT

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



15 years ago
the build worked fine on 8/8/2002, and started  failing 8/9/2002
building NSPR_4_2_RELEASE passes on the same machine

checking for cl... no
checking for whoami... echo not_whoami
checking for c++... no
checking for g++... no
checking for gcc... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking whether the C++ compiler (gcc  ) works... no
configure: error: installation or configuration problem: C++ compiler cannot
create executables.
Elapsed Time = 00:00:05
Fri 9 Aug 2002 03:30:55

which cl will give


This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:618: checking host system type
configure:639: checking target system type
configure:657: checking build system type
configure:722: checking for cl
configure:993: checking for whoami
configure:1849: checking for c++
configure:1849: checking for g++
configure:1849: checking for gcc
configure:1849: checking for CC
configure:1849: checking for cxx
configure:1849: checking for cc++
configure:1849: checking for cl
configure:1881: checking whether the C++ compiler (gcc  ) works
configure:1897: gcc -o conftest    conftest.C  1>&5
gcc: eval: ../mozilla/nsprpub/configure 2641: not found
configure: failed program was:

#line 1892 "configure"
#include "confdefs.h"

int main(){return(0);}

Comment 1

15 years ago
Created attachment 95504 [details] [diff] [review]
Proposed patch

Chris, it seems that rev. 1.115 of mozilla/nsprpub/configure.in
broke the Win32 build under the MKS Toolkit.  I think that
AC_CHECK_PROGS does not work under MKS.

This patch backs out the mksnt portion of rev. 1.115.
I'm confused. I thought that NSPR_4_2_RELEASE was a static tag? Or were you
referring to the trunk/moz 8/8 & 8/9 builds?  

We should have a better check for cl.exe than just relying upon the uname.  If
someone's path isn't setup correctly, that should be caught by configure not
later during the build of nsinstall.

Can you attach the output of 'sh -x configure' ?  I'd like to see where
AC_CHECK_PROGS is failing.

Comment 3

15 years ago
Created attachment 95525 [details]
Output of 'sh -x configure' under MKS Korn Shell

NSPR_4_2_RELEASE is a static tag.  I believe Sonja
was referring to the trunk of NSPR on 8/8 and 8/9.

Comment 4

15 years ago
As the output of 'sh -x configure' shows, AC_CHECK_PROGS
has two problems under MKS Korn Shell.

1. MKS Korn Shell uses ; as the path separator in its PATH
environment variable, and the PATH contains : after the
drive letters.  On the other hand, configure uses : as the
path separator, so MKS's PATH is incorrectly broken down
at the : after the drive letters.

2. Even if I manually fix configure to use ; as the path
separator, 'test -f <msvc install dir>/cl' is false under
MKS.  You need to supply the .exe suffix, that is, only
'test -f <msvc install dir>/cl.exe' is true.

It's quite difficult to make AC_CHECK_PROGS work under
MKS Korn Shell.  This is why I suggested that we skip
these checks under MKS.

Comment 5

15 years ago
Created attachment 95529 [details] [diff] [review]
Proposed patch v2

Also need to back out the msvc portion of rev. 1.114.
Attachment #95504 - Attachment is obsolete: true

Comment 6

15 years ago
I checked in the fix on the tip and
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.3
Version: 4.2 → 4.3

Comment 7

15 years ago
works now again in the iPlanet daily build
You need to log in before you can comment on or make changes to this bug.