Closed Bug 215224 Opened 21 years ago Closed 19 years ago

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

Categories

(SeaMonkey :: Build Config, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: murphye, Assigned: chase)

References

Details

Attachments

(1 file)

ftp://ftp.mozilla.org/pub/mozilla/libraries/win32/vc7-glib-1.2.10-bin.zip
ftp://ftp.mozilla.org/pub/mozilla/libraries/win32/vc7-libIDL-0.6.8-bin.zip

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
msvcr71.dll.

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
why. *I NEED HELP WITH THIS*

Also see: http://bugzilla.mozilla.org/show_bug.cgi?id=208314 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.
Adding Daniel Nunes as a CC. He wrote: 
http://www.mozilla.org/build/win32.html

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).
http://bugzilla.mozilla.org/show_bug.cgi?id=208461#c7 is Hixie's meta VC7.1
patch, if you could call it a meta patch, that has the configure.in changes.
Patches to configure aren't generally attached because of the
sometimes-auto-updating script that checks in the configure changes when
configure.in is touched, and most people hacking configure.in 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
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=ba9isr%24cec2%40ripley.netscape.com?
Depends on: 213313
Depends on: 215347
No longer depends on: 213313
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\Makefile.in 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.
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
VC7.1 went to the <iomanip> version of that header.
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.
If anyone runs into other header problems, the headers that changed are listed
at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Differences_in_iostream_implementation.asp

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

DEFINES += -DREGISTER_PROXY_DLL -DUNICODE -D_UNICODE -D_WIN32_WINNT=0x400
This vsvars7.sh could be added to some documentation to make things easier for
developers to compile from Cygwin with VS.NET 2003.
Setting environment variables in vsvars7.sh 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 vsvars7.sh 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
If you are familiar with .NET, please check out this bug I have opened:
http://bugzilla.mozilla.org/show_bug.cgi?id=221446

It's about building Mozilla with the /clr switch (which I was able to do).
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 
supported?
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?
Depends on: 236956
All dependencies have been fixed.  According to cls in Bug 208345, the build
page ( http://www.mozilla.org/build/win32.html ) needs to be updated.

After that is done, this bug can be closed.
Depends on: 240629
I just seen on Slashdot that Microsoft is now offering Microsoft Visual C++
Toolkit 2003 for free.

http://msdn.microsoft.com/visualc/vctoolkit2003/

This is worth documenting and linking to on the build documentation page.
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:

Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.1344
diff -u -r1.1344 configure.in
--- configure.in        13 May 2004 03:12:47 -0000      1.1344
+++ configure.in        13 May 2004 10:16:28 -0000
@@ -1187,7 +1190,7 @@
     AC_DEFINE(HW_THREADS)
     AC_DEFINE_UNQUOTED(WINVER,0x400)
     AC_DEFINE(STDC_HEADERS)
-    AC_DEFINE(NEW_H, <new>)
+    AC_DEFINE(NEW_H, <new.h>)
     AC_DEFINE(WIN32_LEAN_AND_MEAN)
     TARGET_MD_ARCH=win32
     _PLATFORM_DEFAULT_TOOLKIT='windows'

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...
Assignee: leaf → cmp
Product: Browser → Seamonkey
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.
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: