Cannot build using VC++ .NET 2003 / vc7.1



16 years ago
13 years ago


(Reporter: murphye, Assigned: chase)


Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago

These do not seem to work building with 2003. That is because 2003 is now
considered vc7.1 and there is no longer msvcr70.dll, which is replaced by

I have built a new glib using 2003, but I am having troubles building libIDL.
This might be because of changes in the 2003 C compiler (which is more strict,
from what I have read). I am getting a lot of syntax errors, and I have no clue

Also see: Note: The patch
here has also forgotten to make a needed change to configure.

It would be cool if we could get 1.5 to build with VC++ .NET 2003. If I can
somehow get libIDL to compile, get the files online and docs updated, and we get
the other patch in... should be good to go.

I hope someone can get in contact with me so I can compile libIDL. It may
involve updating its C code. All of the errors I have seen so far are coming
from util.c.

Comment 1

16 years ago
Adding Daniel Nunes as a CC. He wrote:

This document will need to be updated.
Most of the issues in comment 0 are covered in bug 208345, but this seems like a
good bug to turn into a meta-bug (especially since bug 208314 comment 7
suggested this bug should cover all remaining isssues).

Comment 3

16 years ago is Hixie's meta VC7.1
patch, if you could call it a meta patch, that has the changes.
Patches to configure aren't generally attached because of the
sometimes-auto-updating script that checks in the configure changes when is touched, and most people hacking will just run
'autoconf' to generate the new configure.

dbaron/leaf, do you want the new libIDL/glib uploaded to ftp.m.o eventually so
people won't need to build them or do you agree with what cls said in


16 years ago
Depends on: 213313


16 years ago
Depends on: 215347
No longer depends on: 213313

Comment 4

16 years ago
Using the updated libIDL/glib, applying Hixie's patch from bug 208461 (you'll
get easy to fix conflicts when updating after applying the patch), adding the
-D_WIN32_WINNT=0x400 to mapihook\build\ as Pauli commented, applying
bsmedberg's patch from bug 212919, and applying jpierre's patch from bug 215347
an opt Thunderbird build compiles.  I didn't try building any other apps, but
they *should* work.

Comment 5

16 years ago
I am building now using ALL of the patches to the attached bugs, and it seems to
be working. I had some initial trouble because I didn't have
ac_add_options --disable-tests

Here is the first error I got from that:
c:/mozilla\xpcom\tests\TestObserverService.cpp(49) : fatal error C1083: Cannot
open include file: 'iomanip.h': No such file or directory

Comment 6

16 years ago
VC7.1 went to the <iomanip> version of that header.

Comment 7

16 years ago
OK, now I got an error:
c:/mozilla\mailnews\mapi\mapihook\build\msgMapi_p.c(85) : fatal error C1189:
#error :  You need a Windows NT 4.0 or later to run this stub because it uses
these features:

My Makefile looks fine, and I did a make clean on the mapi stuff to be sure, but
still get it.

Comment 8

16 years ago
If anyone runs into other header problems, the headers that changed are listed

Eric, I ran into that as well. -D_WIN32_WINNT=0x400 needs to be added to the
mapihook\build\ define line.  The line should look like:


Comment 9

16 years ago
Created attachment 132563 [details]
In Cygwin, do 'source' to setup environment variables to compile with VS.NET 2003

This could be added to some documentation to make things easier for
developers to compile from Cygwin with VS.NET 2003.

Comment 10

16 years ago
Setting environment variables in is a BAD idea, mainly because not
everybody will have installed VS .NET 2003 in the default location.  When it is
installed, VS .NET 2003 creates a VS .NET 2003 Command Prompt under VS .NET
Tools on the Start Menu that does everything does, with the paths
that are correct for that system, even if it is not installed in the default
location.  If we want to document something, we should tell people to use the VS
.NET 2003 Command Prompt.
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf

Comment 12

16 years ago
If you are familiar with .NET, please check out this bug I have opened:

It's about building Mozilla with the /clr switch (which I was able to do).

Comment 13

16 years ago
I was building just fine with vc7.1 until a few days ago.  Now, my non-debug 
build works, but my debug build crashes on startup.  Has anyone else seen this?

I guess I need to go back all those iostream.h -> iostream changes and see if 
I missed some important checkin. In any case, when will this compiler be 

Comment 14

16 years ago
Magically, the crash is gone after I pulled a new system this morning.
So, except for the libIDL issue (which can be worked around), this seems fixed.
 Does someone have the resources to set up a tinderbox?


15 years ago
Depends on: 236956

Comment 16

15 years ago
All dependencies have been fixed.  According to cls in Bug 208345, the build
page ( ) needs to be updated.

After that is done, this bug can be closed.


15 years ago
Depends on: 240629

Comment 17

15 years ago
I just seen on Slashdot that Microsoft is now offering Microsoft Visual C++
Toolkit 2003 for free.

This is worth documenting and linking to on the build documentation page.

Comment 18

15 years ago
Another problem with VC 7.1:

Operator new() now throws an exception instead of returning NULL, so mozilla
exits instead of handling out of memory gracefully.
To have the "old" new() behaviour, you can include <new.h> and not <new>

It works for me:

RCS file: /cvsroot/mozilla/,v
retrieving revision 1.1344
diff -u -r1.1344
---        13 May 2004 03:12:47 -0000      1.1344
+++        13 May 2004 10:16:28 -0000
@@ -1187,7 +1190,7 @@
-    AC_DEFINE(NEW_H, <new>)
+    AC_DEFINE(NEW_H, <new.h>)

Comment 19

15 years ago
Compiling with only the free toolkit won't always work. If XPC_IDISPATCH_SUPPORT
is defined, then js/src/xpconnect/src/xpcprivate.h includes atlbase.h, one of
the ATL (Active Template Library) headers. This library is NOT shipped with the
free toolkit. XPConnect fails to compile with XPC_IDISPATCH_SUPPORT (the default).
the _real_ solution for the OOM crashes is using something like new
(std::nothrow) instead of just new; that way, all platforms will benefit...


14 years ago
Assignee: leaf → cmp
Product: Browser → Seamonkey

Comment 21

14 years ago
For what it's worth VC++'s "new" has thrown exceptions since version 6 and 
probably earlier. Mozilla is built without exceptions enabled for VC++ so new 
never throws exceptions in those cases. I would think Mozilla should be built 
without exceptions under VS .Net 2003 as well.

Comment 22

13 years ago
I've been building pretty much all of our code with VC7.1 for a while now. The Free toolkit compiler has issues out of the box, but the profession-edition compiler works. Please file new bugs for new issues that come up.
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.