209664 - "cl not found" when compiling under gcc with no MSVC

Status: NEW

(NSPR :: NSPR, defect, P3)

Description

[Henrik Gemal]

make[4]: Entering directory `/cygdrive/c/Mozilla/mozilla/nsprpub/config'
sh /cygdrive/c/Mozilla/mozilla/nsprpub/build/cygwin-wrapper cl -Fonow.obj -c
 -W3 -nologo -GF -Gy -MDd -Od -Z7   -UNDEBUG -DDEBUG_hege -UWINNT  -DMOZILLA_CLI
ENT=1 -DDEBUG=1 -DXP_PC=1 -DWIN32=1 -D_DEBUG=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ON
LY=1 -D_X86_=1  -DFORCE_PR_LOG   /cygdrive/c/Mozilla/mozilla/nsprpub/config/now.
c
exec: cl: not found
make[4]: *** [now.obj] Error 127

cl seems to be hardcoded. Doesn't is compile without Microsoft C++?

Comment 1

[Henrik Gemal]

due to using cygwin gcc and not mingw gcc

Comment 2

[hacker formerly known as [e-mail]]

Actually, it's due to using netscape's uname instead of cygwin's.  The check
that hardcodes _WIN32_MSVC based upon uname is really broken and should be fixed.

Comment 3

[Henrik Gemal]

should I file a new bug with the uname issue?

Comment 4

[Henrik Gemal]

I've opened bug http://bugzilla.mozilla.org/show_bug.cgi?id=210066

Comment 5

[hacker formerly known as [e-mail]]

No, there's no need for a new bug.  The problem is with NSPR's configure.in not
the uname binary (non-standard as it may be).

Comment 6

[hacker formerly known as [e-mail]]

Taking.

Comment 7

[Stephen Walker]

*** Bug 210227 has been marked as a duplicate of this bug. ***

Comment 8

[hacker formerly known as [e-mail]]

Attachment: v1.0

Set the default CC/CXX to cl for win32 but allow them to be overridden by env
variables.

Comment 9

[hacker formerly known as [e-mail]]

Comment on attachment 126856 [details] [diff] [review]
v1.0

Wan-Teh, can you test this patch using MKS?  Thanks.

Comment 10

[Brant Gurganus]

I applied this patch to my CVS checkout and my build still failed at that point
when building from win32 command shell.  It went past that point building from
the cygwin bash shell.

Specs for my build environment
non-cygwin gcc and related packages from mingw
WinCVS
ActivePerl

Comment 11

[hacker formerly known as [e-mail]]

Did you run autoconf in the nspr directory after applying the patch?  It
shouldn't matter which command shell is used as they both just invoke the cygwin
tools.  The only thing that might change is the PATH used and therefore the
version of uname used.

Comment 12

[Robert Bamler]

I applied this patch "by hand" after updating the file 
"/mozroot/mozilla/nsprpub/configure.in" from CVS and then tried to build Mozilla 
without cl installed under WinXP. The process doesn't stop any more at the point 
specified above, but I get another error:

In file included from c:/downloads/mozilla/sourcecode/extracted/mozilla/dbm/src/
db.c:54:
c:/downloads/mozilla/sourcecode/extracted/mozilla/dbm/include/mcom_db.h:87:23: s
ys/cdefs.h: No such file or directory

I looked in the file mcom_db.h:

[...]
#ifdef HAVE_SYS_CDEFS_H
#include <sys/cdefs.h>
#else
#include "cdefs.h"
#endif
[...]

I found three files named "cdefs.h":
- mozilla\dbm\include\cdefs.h
- mozilla\dist\include\dbm\cdefs.h
- mozilla\xpinstall\wizard\libxpnet\GUSI\include\sys\cdefs.h

Comment 13

[hacker formerly known as [e-mail]]

The cdefs.h problem is caused by configuring with one variant of win32 gcc and
building with the other.  Do a 'make distclean' and rebuild without changing
your PATH.

Comment 14

[Wan-Teh Chang]

Attachment: config.log under MKS with patch v1.0 applied

Patch v1.0 doesn't work under MKS Toolkit.  This is
the config.log file from a failed run.	The command
line output is as follows:

G:\nspr-tip\mks.dbg>sh ../mozilla/nsprpub/configure --enable-win32-target=WIN95

creating cache ./config.cache
checking host system type... i586-pc-mks
checking target system type... i586-pc-mks
checking build system type... i586-pc-mks
checking for whoami... echo not_whoami
checking for c++... cl
checking whether the C++ compiler (cl  ) works... no
configure: error: installation or configuration problem: C++ compiler cannot
cre
ate executables.

Comment 15

[edmz]

Tried the patch, still cant compile:

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

configure:855: checking host system type
configure:876: checking target system type
configure:894: checking build system type
configure:1900: checking for gcc
configure:2013: checking whether the C compiler (cl  ) works
configure:2029: cl -o conftest    conftest.c  1>&5
cl: not found
configure: failed program was:

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

main(){return(0);}

Comment 16

[cls]

Attachment: v1.1

I think the problem with the previous patch was that $ac_exeext was not set. 
Cygwin will check for foo.exe when doing a stat() on foo.  I'm guessing MKS
will not so we need to explicitly call AC_EXEEXT to use the proper executable
suffix.

When running NSPR's configure directly, you will still have to set CC & CXX to
override the defaults.

Comment 17

[cls]

Attachment: v1.2

We need to call AC_EXEEXT from mozilla's configure as well so that the value is
already set or we have to require that CC be set in the environment (explicitly
export CC from mozconfig) so that NSPR's configure sees so that the macro uses
the proper compiler when testing.

Comment 18

[Wan-Teh Chang]

Comment on attachment 140296 [details] [diff] [review]
v1.2

cls: this patch works under MKS.  I will review the patch
later.	So AC_EXEEXT is the fix?

Here is the configure output:

D:\wtc\nspr-tip\win95.dbg>sh ../mozilla/nsprpub/configure
--enable-win32-target=WIN95
creating cache ./config.cache
checking host system type... i586-pc-mks
checking target system type... i586-pc-mks
checking build system type... i586-pc-mks
checking for whoami... echo not_whoami
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... .exe
checking for c++... cl
checking whether the C++ compiler (cl  ) works... yes
checking whether the C++ compiler (cl  ) is a cross-compiler... no
checking whether we are using GNU C++... no
checking whether cl accepts -g... no
checking for gcc... cl
checking whether the C compiler (cl  ) works... yes
checking whether the C compiler (cl  ) is a cross-compiler... no
checking whether we are using GNU C... no
checking whether cl accepts -g... no
checking how to run the C preprocessor... cl -nologo -E

Comment 19

[Wan-Teh Chang]

Comment on attachment 140296 [details] [diff] [review]
v1.2

Initial review comments:

1. With your patch applied, SKIP_PATH_CHECKS is
useless and can be removed.

2. With your patch applied, SKIP_COMPILER_CHECKS
is not that useful -- it only protects a check
for gcc's -pipe option.  OK to keep it for now.

3. The block protected by SKIP_LIBRARY_CHECKS
contains the following that should not be protected
by SKIP_LIBRARY_CHECKS (these are pre-existing
problems, not introduced by your patch):

  3a. --enable-strip

  3b. HP-UX +Olit support

The --enable-strip stuff should be moved after the
SKIP_LIBRARY_CHECKS block.

The HP-UX +Olit support should be moved to the
general hpux section earlier in the file.

Comment 20

[Wan-Teh Chang]

Comment on attachment 140296 [details] [diff] [review]
v1.2

I looked at the configure results closer.  I found that
it failed to find 'perl' on my machine.

It seems that AC_EXEEXT only helps AC_TRY_COMPILE but not
AC_PATH_PROGS, which we use to find 'perl'.

By the way, we use AC_PATH_PROG to find 'whoami', which
also failed on my machine.  Our AC_PATH_PROG command is
before AC_EXEEXT.  Even if we say AC_EXEEXT before the
AC_PATH_PROG for 'whoami', I am not sure if that'll help.

So it seems that we still need to use SKIP_PATH_CHECKS
to protect AC_PATH_PROG and AC_PATH_PROGS, and we need
to move the AC_PATH_PROG for 'whoami' after we have set
SKIP_PATH_CHECKS.

I think we are very close now :-)

Comment 21

[cls]

Attachment: v1.3

I'm not going to touch the SKIP_LIBRARY_CHECKS issue just yet.	As far as the
AC_PATH_PROGS checks go, I think the easiest thing to do would be to just add
${ac_exeext} to each binary in the search list.  Unfortunately, that will
probably cause cross-compiling to break if the build & target platforms have
different ac_exeext settings.  Soooo, for each entry in the each list, I added
an additional entry with ${ac_exeext} appended.  It looks nasty but it should
still work.

Comment 22

[Neil Katin]

I ran the v1.3 patch on win2k + cygwin environment; the patch did fixed
the problem.

Just a note in case anyone made the same mistake that I did when
applying the patch: you have to run autoconf on the configure.in
files to regenerate the configure files, as per comment #11.

Any chance of getting this integrated into the tree?

Comment 23

[chris hofmann]

cls,  go ahead and get this on the branch if you can in the next few days, but I
don't think we would block on it.

Comment 24

[Tim Weichselbaum]

$ make -f client.mk build_all
cd /c/mozilla/mozilla
./configure
Adding configure options from ./.mozconfig:
  --disable-accessibility
  --disable-activex
loading cache ./config.cache
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking build system type... i686-pc-mingw32
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... no
configure: error: installation or configuration problem: C compiler cannot
create executables.
*** Fix above errors and then restart with "make -f client.mk build"
make: *** [/c/mozilla/mozilla/Makefile] Error 1

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

used Cygwin and MinGW, same exact thing. How do I use the patch to fix this?

Comment 25

[cls]

The problem mentioned in comment #24 is not related to this original bug and
would not be solved by the patch.  You need to look at config.log and see why
gcc wasn't able to create an executable.

Comment 26

[Ryan Sommers]

(In reply to comment #25)
> The problem mentioned in comment #24 is not related to this original bug and
> would not be solved by the patch.  You need to look at config.log and see why
> gcc wasn't able to create an executable.
> 

I believe his comment actually is related to your patch. I just applied your
patch, albeit I had to apply hunk 7 on nsprpub/configure.in by hand. I received
the same error he did. Here is my config.log:

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

configure:621: checking host system type
configure:642: checking target system type
configure:660: checking build system type
configure:965: checking for Cygwin environment
configure:981: cl -c   conftest.c 1>&5
cl: not found
configure: failed program was:
#line 970 "configure"
#include "confdefs.h"

int main() {

#ifndef __CYGWIN__
#define __CYGWIN__ __CYGWIN32__
#endif
return __CYGWIN__;
; return 0; }
configure:998: checking for mingw32 environment
configure:1010: cl -c   conftest.c 1>&5
cl: not found
configure: failed program was:
#line 1003 "configure"
#include "confdefs.h"

int main() {
return __MINGW32__;
; return 0; }
configure:1029: checking for executable suffix
configure:1039: cl -o conftest    conftest.c  1>&5
cl: not found

Comment 27

[Ryan Sommers]

Disregard my last comment. Running autoconf from the src root and then running
make got past that part.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Another sidenote, which may or may not be well known:

When using multiple .mozconfig files that are pointed to using the MOZCONFIG
environment variable under Windows, use /cygdrive/drivename/path/to/mozconfig
instead of drive:\path\to\mozconfig as the mk_add_options *are* picked up by the
DOS path specification, but the ac_add_options and compiler options are *not*
and require the cygdrive path specification.

This took me a few head scratches to figure out, and had been resulting in some
really wacky behaviour where half of my .mozconfig seemed to be taking hold, but
half did not.

Comment 29

[Christophe Ravel]

The target milestone was already released. Resetting target milestone.

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.