Open
Bug 209664
Opened 21 years ago
Updated 1 year ago
"cl not found" when compiling under gcc with no MSVC
Categories
(NSPR :: NSPR, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: bugzilla, Unassigned)
References
Details
Attachments
(2 files, 3 obsolete files)
876 bytes,
text/plain
|
Details | |
4.34 KB,
patch
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
due to using cygwin gcc and not mingw gcc
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Comment 2•21 years ago
|
||
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•21 years ago
|
||
should I file a new bug with the uname issue?
Reporter | ||
Comment 4•21 years ago
|
||
I've opened bug http://bugzilla.mozilla.org/show_bug.cgi?id=210066
Comment 5•21 years ago
|
||
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 → ---
Comment 6•21 years ago
|
||
Taking.
Assignee: wtc → seawood
Status: REOPENED → NEW
Priority: -- → P3
Target Milestone: --- → 4.3.3
Comment 7•21 years ago
|
||
*** Bug 210227 has been marked as a duplicate of this bug. ***
Comment 8•21 years ago
|
||
Set the default CC/CXX to cl for win32 but allow them to be overridden by env variables.
Comment 9•21 years ago
|
||
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•21 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
Comment 11•21 years ago
|
||
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•21 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
Comment 13•21 years ago
|
||
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•21 years ago
|
||
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•21 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•21 years ago
|
||
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•21 years ago
|
||
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
Attachment #126856 -
Flags: review?(wchang0222)
Attachment #140296 -
Flags: review?(wchang0222)
Comment 18•21 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•21 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•21 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•21 years ago
|
||
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
Attachment #140829 -
Flags: review?(wchang0222)
Comment 22•20 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?
Comment 23•20 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•20 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•20 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.
Comment 26•19 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•19 years ago
|
||
Disregard my last comment. Running autoconf from the src root and then running make got past that part.
Comment 28•19 years ago
|
||
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.
Updated•18 years ago
|
QA Contact: wtchang → nspr
Comment 29•17 years ago
|
||
The target milestone was already released. Resetting target milestone.
Target Milestone: 4.3.3 → ---
Updated•2 years ago
|
Severity: normal → S3
Comment 30•1 year ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: netscape → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•