[build] Windows target name changes

Skip to first unread message

Mike Hommey

Feb 23, 2023, 2:54:54 AMFeb 23
to dev-pl...@lists.mozilla.org
(I originally sent this message last week, but only figured now that it
never reached the list because I used an erroneous address)


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

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.



Tom Ritter

Feb 23, 2023, 2:43:00 PMFeb 23
to Mike Hommey, dev-pl...@lists.mozilla.org
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
- 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:

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

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

# x86 Builds

# x64 Builds



mk_add_options "export

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

Reply all
Reply to author
0 new messages