The default bug view has changed. See this FAQ.

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

Status

NSPR
NSPR
P3
normal
14 years ago
10 years ago

People

(Reporter: Henrik Gemal, Assigned: hacker formerly known as seawood@netscape.com)

Tracking

(Blocks: 1 bug)

other
x86
Windows 2000
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

14 years ago
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++?
(Reporter)

Comment 1

14 years ago
due to using cygwin gcc and not mingw gcc
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
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.
(Reporter)

Comment 3

14 years ago
should I file a new bug with the uname issue?
(Reporter)

Comment 4

14 years ago
I've opened bug http://bugzilla.mozilla.org/show_bug.cgi?id=210066
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).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Taking.
Assignee: wtc → seawood
Status: REOPENED → NEW
Priority: -- → P3
Target Milestone: --- → 4.3.3

Comment 7

14 years ago
*** Bug 210227 has been marked as a duplicate of this bug. ***
Created attachment 126856 [details] [diff] [review]
v1.0

Set the default CC/CXX to cl for win32 but allow them to be overridden by env
variables.
Comment on attachment 126856 [details] [diff] [review]
v1.0

Wan-Teh, can you test this patch using MKS?  Thanks.
Attachment #126856 - Flags: review?(wtc)

Comment 10

14 years ago
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
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

14 years ago
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
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

14 years ago
Created attachment 127487 [details]
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

14 years ago
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

13 years ago
Created attachment 140293 [details] [diff] [review]
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.
Attachment #126856 - Attachment is obsolete: true

Comment 17

13 years ago
Created attachment 140296 [details] [diff] [review]
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.
Attachment #140293 - Attachment is obsolete: true

Updated

13 years ago
Attachment #126856 - Flags: review?(wchang0222)

Updated

13 years ago
Attachment #140296 - Flags: review?(wchang0222)

Comment 18

13 years ago
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

13 years ago
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

13 years ago
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 :-)
Attachment #140296 - Flags: review?(wchang0222) → review-

Comment 21

13 years ago
Created attachment 140829 [details] [diff] [review]
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.
Attachment #140296 - Attachment is obsolete: true

Updated

13 years ago
Attachment #140829 - Flags: review?(wchang0222)

Comment 22

13 years ago
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?


Updated

13 years ago
Flags: blocking-aviary1.0?

Comment 23

13 years ago
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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 24

12 years ago
$ 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

12 years ago
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.

Updated

12 years ago
Blocks: 203303

Comment 26

12 years ago
(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

12 years ago
Disregard my last comment. Running autoconf from the src root and then running
make got past that part.
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.
QA Contact: wtchang → nspr

Comment 29

10 years ago
The target milestone was already released. Resetting target milestone.
Target Milestone: 4.3.3 → ---
You need to log in before you can comment on or make changes to this bug.