311923 - fatal error C1083: Cannot open include file: 'new': No such file or directory.

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Robert Claypool]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051008 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051008 Firefox/1.6a1

c:\moz\mozilla\dist\include\string\nsString.h(55) : fatal error C1083: Cannot
open include file: 'new': No such file or directory.

Reproducible: Always

Steps to Reproduce:
make -f client.mk

Actual Results:  
Build terminates building deps for nsDependentString.cpp

Expected Results:  
It appears that the nsString.h is generated after CVS checkout. The generation
process needs to be fixed.

#ifndef nsReadableUtils_h___
#include "nsReadableUtils.h"
#endif

#include NEW_H

  // enable support for the obsolete string API if not explicitly disabled
#ifndef MOZ_STRING_WITH_OBSOLETE_API
#define MOZ_STRING_WITH_OBSOLETE_API 1
#endif

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

that file looks fine, and it's not generated after cvs checkout. What compiler
are you using?

Comment 2

[Darin Fisher]

WORKSFORME.  The build systems are also happy:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey

Comment 3

[Robert Claypool]

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86.

The build process has identified the cygwin \lib\cpp as the C++ preprocessor though.

After checkout during build:
creating pr/tests/Makefile
creating pr/tests/dll/Makefile
creating pr/src/threads/combined/Makefile
configure: warning: Recreating autoconf.mk with updated nspr-config output
make[1]: Leaving directory `/cygdrive/c/moz/mozilla'
make
make[1]: Entering directory `/cygdrive/c/moz/mozilla'
rm -f -rf ./dist/sdk
rm -f -rf ./dist/include
rm: cannot remove directory `./dist/include/string': Device or resource busy
make[1]: *** [default] Error 1
make[1]: Leaving directory `/cygdrive/c/moz/mozilla'
make: *** [build] Error 2

When I had C:/moz/mozilla/dist/include/string open in another directory, so the
string directory under dist gets recreated 'after' checkout.

By the time of the above error, the string directory under dist is already
evacuated.
xpcom\xpcom-config.h reads:

/* Define to either <new> or <new.h> */
#define NEW_H <new>


Changing it to
#define NEW_H <new.h>

allows the build to accept it and continue.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

can you attach config.log?

Comment 5

[Robert Claypool]

Attachment: configure: failed program was: #line 5346 "configure"

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 199093 [details]
configure: failed program was: #line 5346 "configure"

er, is that the entire file?

Comment 7

[Robert Claypool]

Yes, I cheked it again after the build failed for another reason (ucvlatin) and
it appears to be the same. C:\moz\mozilla\config.log If it is supposed to be
more than that, well then the config.log generator is borked.

Comment 8

[Robert Claypool]

Attachment: buildsetup.bat

Comment 9

[Alfred Peng]

I've met the similar build error with this case and got some information from this link: http://www.gigascale.org/softdevel/faq/23.html. Reinstall CygWin in textmode helps me correct the problem.

I suggest that the build document http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites can contain this faq. It's really valuable. Who should I contact with to make it happen?

Comment 10

[Benjamin Smedberg]

Peng, I own the build FAQ though anyone can edit it. I'm happy to add things to the FAQ, but I don't understand what the bug is yet: what are the symptoms, what's the cause, and what's the solution?

Comment 11

[Alfred Peng]

The build error message in my case is similar with this one:
c:\mozilla_src\mozilla\mozillafirebird\dist\include\string\nsString.h(55) : error C2006: '#include' : expected a filename, found 'identifier'
c:\mozilla_src\mozilla\mozillafirebird\dist\include\string\nsString.h(55) : fatal error C1083: Cannot open include file: '': No such file or directory 
It seems that the MACRO NEW_H can't be found.

Meanwhile, the "Makefile"s generated by "configure" all have the ^M charactor at the end of each line. Which causes another build error: "commands commence before first target". It's a Cygwin CR/NL problems I think.

Following the instruction of the FAQ in comment #9, I reinstall cygwin in textmode, this two problems disappear.

As the FAQ said, it's highly recommended that cygwin can be installed in textmode instead of binmode, which can avoid some future problems.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

this bug's summary is highly misleading. fixing.

Comment 13

[Boris Zbarsky [:bzbarsky]]

So is the issue that we define NEW_H to be the wrong thing?  Isn't that just a configure test?

Comment 14

[cls]

We're explicitly using <new.h> to check to see if 'cl' is a valid compiler.  Then we set NEW_H=<new> for wince & win32.  Then we set NEW_H=new.h unconditionally for all platforms.  Using the builtin AC_CHECK_HEADER macro, if <new> exists, then we set NEW_H=new.

So for whatever reason, it appears as the header test thinks <new> is valid.  Peng, can you attach the 'sh -x configure' output?

cygwin in binmode has worked fine for years.  It sounds like you're mixing & matching cygwin tools & native win32 tools which expect different line-endings.  Are you using cygwin cvs to pull your tree or some other version?

Comment 15

[cls]

Turns out that the AC_CHECK_HEADER call is inside a large SKIP_COMPILER_CHECKS block so it's never run for msvc builds.  So we're just unconditionally setting NEW=<new> per bug 155852.

Comment 16

[Alfred Peng]

(In reply to comment #14)
> So for whatever reason, it appears as the header test thinks <new> is valid. 
> Peng, can you attach the 'sh -x configure' output?

Currently, my cygwin is in textmode. Do you want the output for binmode or textmode?

> cygwin in binmode has worked fine for years.  It sounds like you're mixing &
> matching cygwin tools & native win32 tools which expect different line-endings.
>  Are you using cygwin cvs to pull your tree or some other version?

The cvs I'm using:(cvs -v)
Concurrent Versions System (CVS) 1.11.17 (client/server)
Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn,
                 Jeff Polk, and other authors

Comment 17

[cls]

I wanted to see the configure calls that led to the error so you would have to be using binmode.  However, I'm not sure if that portion of the bug is relevant at this point.  What does 'cygcheck cvs' return?

Comment 18

[Alfred Peng]

$ cygcheck cvs
Found: F:\build\cygwin\bin\cvs.exe
F:/build/cygwin/bin/cvs.exe
  F:\build\cygwin\bin\cygcrypt-0.dll
    F:\build\cygwin\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\KERNEL32.dll
        C:\WINDOWS\system32\RPCRT4.dll
  F:\build\cygwin\bin\cyggdbm-4.dll
  F:\build\cygwin\bin\cyggdbm_compat-4.dll

Comment 19

[Alfred Peng]

I reinstalled cygwin in binmode. There is no error in the build process. I can't reproduce it.:(

Comment 20

[Bob Spencer]

Attachment: firefox-statix/config.log (nsString.h error)

I'm seeing this error after checking out the head using cygwin binmode.  I am using a binary cvs version I downloaded (1.12.13) instead of the cygwin cvs version (1.11.17) because I wanted proxy support.

> cygwin in binmode has worked fine for years.  It sounds like 
> you're mixing & matching cygwin tools & native win32 tools 
> which expect different line-endings. Are you using cygwin 
> cvs to pull your tree or some other version?

I'm hearing that one possible solution may be to get the cvs 1.12.x source and rebuild it in cygwin.  Correct?  Is there a quick way to verify that this is the cause of the problem?

Build output:
...
make[6]: Entering directory `/cygdrive/c/src/moz/mozilla/firefox-static/xpcom/string/src'
nsDependentString.cpp
Building deps for /cygdrive/c/src/moz/mozilla/xpcom/string/src/nsDependentString.cpp
/cygdrive/c/src/moz/mozilla/build/cygwin-wrapper cl -FonsDependentString.obj -c ... /cygdrive/c/src/moz/mozilla/xpcom/string/src/nsDependentString.cpp
nsDependentString.cpp
c:\src\moz\mozilla\firefox-static\dist\include\string\nsString.h(55) : error C2006: '#include' : expected a filename, found 'identifier'
c:\src\moz\mozilla\firefox-static\dist\include\string\nsString.h(55) : fatal error C1083: Cannot open include file: '': No such file or directory
make[6]: *** [nsDependentString.obj] Error 2

Comment 21

[cls]

(In reply to comment #20)
> I'm hearing that one possible solution may be to get the cvs 1.12.x source and
> rebuild it in cygwin.  Correct?  Is there a quick way to verify that this is
> the cause of the problem?

Assuming that cvs 1.12.x builds out of the box for cygwin, then rebuilding cvs using cygwin should solve your problem.  

For quick verification that building using binmode works, download the nightly source tarball and unpackage it using cygwin tar & gzip/bzip2. 

Per http://groups.google.com/group/mozilla.dev.builds/browse_frm/thread/7bcf8e3acc333280/b1a32b802e976a84#b1a32b802e976a84 , do not use WinZIP (or a non-cygwin unzip) to unpackage the tarball.  It can cause the same error to appear.

This bug should be closed as INVALID.  I'm mildly curious as to why the line-ending differences cause NEW_H to be not substituted but I have the feeling that this falls under "undefined" behavior when mixing & matching line-ending tools so I'm dropping it.

Comment 22

[Kerem Kat]

I hit this bug on Windows 10 x64 with Visual Studio 15.6, clobber resolved the issue for me.