Closed
Bug 162912
Opened 22 years ago
Closed 22 years ago
configure fails on NT
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
4.3
People
(Reporter: sonja.mirtitsch, Assigned: wtc)
Details
Attachments
(2 files, 1 obsolete file)
43.00 KB,
text/plain
|
Details | |
789 bytes,
patch
|
Details | Diff | Splinter Review |
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 d:\i386\mvvc6.0sp4\vc\bin\cl.exe ============ 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);}
Assignee | ||
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
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.
Assignee | ||
Comment 3•22 years ago
|
||
NSPR_4_2_RELEASE is a static tag. I believe Sonja was referring to the trunk of NSPR on 8/8 and 8/9.
Assignee | ||
Comment 4•22 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.
Assignee | ||
Comment 5•22 years ago
|
||
Also need to back out the msvc portion of rev. 1.114.
Attachment #95504 -
Attachment is obsolete: true
Assignee | ||
Comment 6•22 years ago
|
||
I checked in the fix on the tip and NSPRPUB_PRE_4_2_CLIENT_BRANCH of NSPR.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.3
Version: 4.2 → 4.3
Reporter | ||
Comment 7•22 years ago
|
||
works now again in the iPlanet daily build
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•