555485 - [Win2K] "debug_util_win.cc(262) : error C3861: 'CaptureStackBackTrace': identifier not found"

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Serge Gautherie (:sgautherie)]

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.

Comment 1

[Serge Gautherie (:sgautherie)]

(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.

Comment 3

[Serge Gautherie (:sgautherie)]

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

Back to blocker, per that bug.

Comment 4

[Damon Sicore (:damons)]

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

Comment 5

[Serge Gautherie (:sgautherie)]

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

Comment 6

[Serge Gautherie (:sgautherie)]

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.

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) configure.in: error out when trying to build IPC support without Windows Vista SDK or newer

Per your comment 7.

Comment 9

[Serge Gautherie (:sgautherie)]

Attachment: (Av2) configure.in: be more explicit and stricter when building without needed Windows SDK [Backed out: See comment 19]

NS_ENABLE_TSF will be further sorted out in bug 599893.

Comment 10

[(not currently active) Ted Mielczarek]

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 11

[Serge Gautherie (:sgautherie)]

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 12

[(not currently active) Ted Mielczarek]

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 13

[Serge Gautherie (:sgautherie)]

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 14

[Serge Gautherie (:sgautherie)]

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.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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

Comment 16

[Serge Gautherie (:sgautherie)]

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 :-<

Comment 17

[Serge Gautherie (:sgautherie)]

(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 :-<

Comment 18

[(not currently active) Ted Mielczarek]

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

Comment 19

[Serge Gautherie (:sgautherie)]

(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

Comment 20

[Serge Gautherie (:sgautherie)]

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

Comment 21

[Serge Gautherie (:sgautherie)]

(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...

Comment 22

[Serge Gautherie (:sgautherie)]

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 :-)