After tracemonkey bug 549207 fix, I discovered I currently have to add --disable-ctypes for bug 551724, then my local build fails later with: { .../ipc/chromium/src/base/debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found } I don't know why I now hit this :-( Code is { 261 // TODO(ajwong): Migrate this to StackWalk64. 262 int count = CaptureStackBackTrace(0, kMaxCallers, callers, NULL); } http://msdn.microsoft.com/en-us/library/bb204633(VS.85).aspx { Minimum supported client Windows XP Minimum supported server Windows Server 2003 } Obviously, I should not be building this code. NB: I have VS8E and 2003R2 SDK.

(In reply to comment #0) > I don't know why I now hit this :-( Oh, I must not have built Firefox since http://hg.mozilla.org/mozilla-central/rev/fc6ed914e44e "Build the pieces of the chromium code we actually need. Many thanks to bent for doing this the first time: I redid the Makefile to be all in one directory and use vpath directives so that dependencies work correctly." --disable-ipc lets my build complete. Then, either this code needs to be fixed, or an explicit check added in configure.in until then.

(In reply to comment #2) > *** Bug 558559 has been marked as a duplicate of this bug. *** Back to blocker, per that bug.

Not sure I understand why this is nominated. Can you explain? Clearing for now, but please re-nom with a detailed reason.

5,5 months without being able to run Debug Firefox builds: not helpful when trying to check/fix tests :-(

Ftr, SeaMonkey has just switched to libxul (bug 394502) then enabled ipc (bug 545716). I downloaded a Debug Windows build and I'm now seeing this bug instead of bug 562820.

We do not intend to make debug builds work on win2k. The only thing I would accept for this bug is a configure patch requiring a new-enough version of the Windows SDK.

Per your comment 7.

NS_ENABLE_TSF will be further sorted out in bug 599893.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] >+if test -n "$COMPILE_ENVIRONMENT"; then >+dnl ======================================================== >+dnl = (Windows) Text Services Framework >+dnl ======================================================== >+case "$target_os" in >+ msvc*|mks*|cygwin*|mingw*) >+ if test -z "$GNU_CC" -a -n "$NS_ENABLE_TSF" -a "$MOZ_WINSDK_TARGETVER" -lt "06000000"; then >+ # (We chose to assume that) TSF is a Windows Vista SDK (or newer) feature. (See bug 88831 comment 135) >+ AC_MSG_ERROR([TSF can't be built with your SDK which only supports Windows up to version $MOZ_WINSDK_MAXVER. Install and use Windows Vista SDK or newer, or do not set NS_ENABLE_TSF=1. Alternatively, try running the Windows SDK Configuration Tool and selecting a newer SDK. See https://developer.mozilla.org/En/Windows_SDK_versions for more details on fixing this.]) Instead of saying "do not set X", you should give the option that the user needs to use to avoid this error, like "you can specify --disable-whatever". Please fix that in all of your error messages. r=me with that change.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] (In reply to comment #10) Your comment makes sense, but I'm not sure that it applies to these cases. 1) There is currently no '--*able-tsf'. 2) Correct default values are/would_be set: see the 'AC_MSG_WARN()' blocks. Then, if the user is getting errors, it's only because he tried to override them, when he shouldn't. So, specifying '--disable-*' would just be redundant with the defaults. In other words, I would agree with you if we removed the defaults and forced the user to explicitly disable these features, but I don't think we want to cause this burden.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] Ok, that's fine then.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] "approval2.0=?": Configure fixes for building with older SDK, no risk.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] http://hg.mozilla.org/mozilla-central/rev/2313b1b0e0d5 Av2, with sorted OS list and not adding cygwin.

I backed out all the changesets in your push because they weren't approved.

Comment on attachment 478810 [details] [diff] [review] (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19] (In reply to comment #15) > I backed out all the changesets in your push because they weren't approved. See discussion in bug 595756 :-<

(In reply to comment #4) > Not sure I understand why this is nominated. Can you explain? It was nominated because build fails on a tier-1 platform :-<

Too late, don't care. We're just going to bump the minimum supported platform post-4.0.

(In reply to comment #15) > I backed out all the changesets in your push because they weren't approved. http://hg.mozilla.org/mozilla-central/rev/43dc221c45ad

Bug 639754 removed 'MOZ_IPC', which is always 'on' now.

(In reply to Serge Gautherie (:sgautherie) from comment #0) > .../ipc/chromium/src/base/debug_util_win.cc(262) : error C3861: > 'CaptureStackBackTrace': identifier not found > } Ftr, there is another affected file: { process_util_win.cc .../ipc/chromium/src/base/process_util_win.cc(560) : error C2065: 'PSAPI_WORKING_SET_INFORMATION' : undeclared identifier ... .../ipc/chromium/src/base/process_util_win.cc(737) : error C2065: 'HeapEnableTerminationOnCorruption' : undeclared identifier } NB: I have a bare workaround for both, locally...

And a 3rd/last error, on Debug builds: something like "firefox.exe : Missing entry point SymFromAddr in dbghelp.dll" This one is in debug_util_win.cc too. NB: I have a bare workaround for it too locally, and I can build a runnable debug Firefox from Try with it, at last :-)