1741233 - `wasm2c` fails to cross compile from a Win64 host to a Win32 target

Status: NEW

(Firefox Build System :: General, defect, P3)

Description

[Nick Alexander :nalexander [he/him]]

With ac_add_options --target=i686-pc-mingw32 on a Win64 host (Windows 10, in this case), I see errors like:

0:12.04 In file included from c:/Users/nalexander/Mozilla/gecko/third_party/wasm2c/src/color.cc:25:
 0:12.04 In file included from c:/Users/nalexander/.mozbuild/vs2017_15.8.4/SDK\include\10.0.17134.0\um\windows.h:172:
 0:12.04 c:/Users/nalexander/.mozbuild/vs2017_15.8.4/SDK\include\10.0.17134.0\um\winbase.h(9233,32): error: use of undeclared identifier 'InterlockedIncrement64'; did you mean '_InterlockedIncrement64'?
 0:12.04     return (unsigned __int64) (InterlockedIncrement64)((volatile __int64*) Addend);

The failing commands look like:

c:/Users/nalexander/.mozbuild/clang/bin/clang-cl.exe -Xclang -std=c++17 -Fohost_color.obj -c  -O2 -DDEBUG=1 -Wno-implicit-fallthrough -Ic:/Users/nalexander/Mozilla/gecko/config/external/wasm2c_sandbox_compiler -Ic:/Users/nalexander/Mozilla/objdirs/objdir-browser-compile32/config/external/wasm2c_sandbox_compiler -Ic:/Users/nalexander/Mozilla/gecko/third_party/wasm2c -Ic:/Users/nalexander/Mozilla/objdirs/objdir-browser-compile32/dist/include -Xclang -MP -Xclang -dependency-file -Xclang .deps/host_color.obj.pp -Xclang -MT -Xclang host_color.obj -Ic:/Users/nalexander/Mozilla/objdirs/objdir-browser-compile32/dist/include/nspr c:/Users/nalexander/Mozilla/gecko/third_party/wasm2c/src/color.cc

The work-around is to use

ac_add_options --without-wasm-sandboxed-libraries

:glandium and I theorize this is Yet Another Problem with using INCLUDE in the environment rather than passing paths on the command line. Not sure if we have a ticket for improving that.

Comment 2

[Bob Owen (:bobowen)]

The option should be:
ac_add_options --without-wasm-sandboxed-libraries

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Bob Owen (:bobowen) from comment #2)

The option should be:
ac_add_options --without-wasm-sandboxed-libraries

Thanks! I've fixed the original comment, for the next person.

Comment 4

[Nick Alexander :nalexander [he/him]]

Looks like more folks are running into this. We could prevent a little frustration by testing host and target around https://searchfox.org/mozilla-central/rev/a3decf626dabd89620171f0ea7840cc4351fe218/toolkit/moz.configure#2359.

Comment 5

[Mike Hommey [:glandium]]

Automatically disabling the feature, while attractive, is not something we should do IMO. A visible error during configure would be more acceptable.

Comment 6

[Shravan Narayan]

Sorry, I just became aware of this bug. Is this still an open issue? If so, is there anything specific to wasm2c causing an issue --- the error looks like it is coming from the Windows SDK itself. If this is a wasm2c issue, I can look into a fix for this upstream.

Comment 7

[Mike Hommey [:glandium]]

No, it's entirely a build system problem.

Comment 8

[Shravan Narayan]

As a temporary workaround, I have applied an in-tree patch to wasm2c to remove the dependency on windows headers (Bug 1831227), and re-enable wasm sandboxing on Windows cross builds. We probably want to keep this bug to track the more general problem of host programs using the wrong headers, but with this workaround wasm sandboxing should no longer be dependent on this.