[build] Windows target name changes

[Mike Hommey]

(I originally sent this message last week, but only figured now that it
never reached the list because I used an erroneous address)

Hi,

So far, Windows targets looked like ${cpu}-pc-mingw32, and the default
compiler would be clang-cl, building for the MSVC-compatible Application
Binary Interface (ABI). One could switch to the clang compiler to build
for the MINGW ABI, which means that ironically, the build target didn't
reflect reality in the default case.

As of bug 1817372, two new target suffixes are allowed in Windows target
names, and the default has changed.

The suffixes are -windows-msvc and -windows-gnu (instead/in addition to
-mingw32), which, if you know the Rust compiler targets, will sound
familiar.

The default is now ${cpu}-pc-windows-msvc instead of ${cpu}-pc-mingw32,
which also means the default objdir name is now
obj-${cpu}-pc-windows-msvc instead of obj-${cpu}-pc-mingw32.

When using the ${cpu}-pc-windows-msvc target, the only supported
compiler is clang-cl, and when using the ${cpu}-pc-windows-gnu target,
the only supported compiler is clang, making things all clearer for the
build system, although the -windows-gnu builds probably don't work out
of the box yet.

For now, the ${cpu}-pc-mingw32 target form is kept, with the same
meaning as before, but will eventually be either removed, or made
synonymous to ${cpu}-pc-windows-gnu.

If you are building on Windows, you probably don't need to change
any configuration (although if you have some --host or --target around
with the -mingw32 form, you may want to remove those flags entirely).
You'll have to be mindful of the objdir name change.

If you are cross-compiling, you should change the --target from
-minwg32 to -windows-msvc.

Cheers,

Mike

[Tom Ritter]

If anyone is confused or curious about the MinGW builds, here are some
fast facts:

- We do these to avoid breaking the build for Tor, they already have
a high maintenance burden keeping up with us, so it's very helpful to
them to keep these working
- Tor uses MinGW because the Windows SDK is not free as in speech
- We do not have the Tor-style reproducible builds in Treeherder, but
there are some other reproducible jobs in-tree, and they do help
- Tor Browser follows ESR on Desktop, and the normal Release train
for Android, although sometimes android releases will be delayed if
there are not marked security bugs
- Sometimes the MinGW build breaks because MinGW doesn't have a
function or constant you need specified in their headers.
Instructions for debugging this will follow.
- If you hit this case, you can #ifdef your way to a green build, but
I strongly request you file a bug blocking
https://bugzilla.mozilla.org/show_bug.cgi?id=mingw-clang that just
says "I had to ifdef stuff over in Bug <foo>, we should clean that up
when we can." I'll get around to it. (I just did a cleanup the other
week.)
- MinGW builds (which target Windows) are not buildable on Windows, only Linux.
- It is moderate difficulty to get your own MinGW builds working
locally, but doable. Terse instructions will follow.
- It is not easy to `./mach test` tests built with MinGW, because
they have to be transferred from the linux machine to Windows. I say
'not easy', because obviously taskcluster does it somehow, but no one
I know has ever succeeded in doing it.
- Before we had mingw clang builds, we had mingw-gcc builds. These
builds had _no_ debugging symbols or information at all. A great man
named David Major found and fixed a _lot_ of MinGW header errors
working with WinDBG in this environment.

--------------------
Debugging missing symbols

Go to https://searchfox.org/mingw-moz/source/ and see if the symbol is
in the MinGW headers. This is the mingw version we use in -central,
although we add some patches:
https://searchfox.org/mozilla-central/source/taskcluster/scripts/misc/build-clang-mingw.sh#40-50

If it's not there, that's going to be your problem. For curiosity's
sake, look at https://searchfox.org/mingw/source/ and see if the
symbol is in MinGW upstream tip. After satiating your curiosity, use
some #ifndef __MINGW32__ to avoid the problematic function calls or
some #define to define the constants you need.

It's possible to clone mingw-w64 upstream, edit the files, git commit
and git format-patch, and copy the patch into the build-clang-mingw
patch list, then hg add the patch and send it in to try to see if that
fixes things. You don't have to do this, but you're a saint if you
do.

-----------------
Local MinGW Builds

Browse https://firefox-ci-tc.services.mozilla.com/tasks/index/gecko.cache.level-3.toolchains.v3
and download the following toolchains (you'll probably have the rest,
like wine and upx):
- linux64-clang-mingw-x86 or x64
- mingw32-rust
- sysroot-wasm32-wasi
- linux64-mingw-fxc2-x86 (it's x86 for both the x86 and x64 builds)

Set up a mozconfig that looks like the following:

# x86 Builds
#ac_add_options --target=i686-pc-windows-gnu
#ac_add_options --with-toolchain-prefix=i686-w64-mingw32-

# x64 Builds
ac_add_options --target=x86_64-pc-windows-gnu
ac_add_options --with-toolchain-prefix=x86_64-w64-mingw32-

ac_add_options --disable-warnings-as-errors
mk_add_options "export WIDL_TIME_OVERRIDE=0"

# This replicates Tor's configuration
ac_add_options --enable-proxy-bypass-protection

# These aren't supported on mingw at this time
ac_add_options --disable-webrtc # Bug 1393901
ac_add_options --disable-geckodriver # Bug 1489320
ac_add_options --disable-update-agent # Bug 1561797
ac_add_options --disable-default-browser-agent # WinToast does not
build on mingw
ac_add_options --disable-notification-server

# Find our toolchain
HOST_CC="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/clang"
HOST_CXX="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/clang++"

# x86 Builds
#CC="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/i686-w64-mingw32-clang"
#CXX="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/i686-w64-mingw32-clang++"

# x64 Builds
CC="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/x86_64-w64-mingw32-clang"
CXX="/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin/x86_64-w64-mingw32-clang++"

CXXFLAGS="-fms-extensions"

RUSTC="/home/tom/Documents/moz/mozilla-unified/toolchain/rustc/bin/rustc"

mk_add_options "export
PATH=/home/tom/Documents/moz/mozilla-unified/toolchain/clang/bin:/home/tom/Documents/moz/mozilla-unified-4/toolchain/fxc2/bin:$PATH"

ac_add_options --with-wasi-sysroot=/home/tom/Documents/moz/mozilla-unified/toolchain/sysroot-wasm32-wasi

-tom

[Biswapriyo Nath]

Thank you for the details. I have tried the above method with latest mozilla-central repository but the mach configure tried to find/download Visual Studio toolchain. Does the above method work now? Do I need to add/change any option?

[Biswapriyo Nath]

The aforementioned issue is being tracked in this bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1920741

The current workaround is to add `ac_add_options --disable-bootstrap` in mozconfig file.