Closed Bug 215224 Opened 21 years ago Closed 19 years ago

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

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: murphye, Assigned: chase)

References

Details

Attachments

(1 file)

In Cygwin, do 'source vsvars7.sh' to setup environment variables to compile with VS.NET 2003
1.89 KB, text/plain
Details
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: