Closed Bug 162912 Opened 22 years ago Closed 22 years ago

configure fails on NT

Categories

(NSPR :: NSPR, defect)

x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: sonja.mirtitsch, Assigned: wtc)

Details

Attachments

(2 files, 1 obsolete file)

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);}
Attached patch Proposed patch (obsolete) — Splinter Review
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.
NSPR_4_2_RELEASE is a static tag.  I believe Sonja
was referring to the trunk of NSPR on 8/8 and 8/9.
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.
Also need to back out the msvc portion of rev. 1.114.
Attachment #95504 - Attachment is obsolete: true
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: