1522614 - gkrust.lib(mdb.o) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'ARM64'

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

The Windows 2012 AArch64 (build-win64-aarch64-msvc) builds (https://treeherder.mozilla.org/#/jobs?repo=try&revision=c2bf1f1e907ae1ac3ad1341ff1de660fc4739bab&searchStr=windows%2C2012%2Caarch64%2Cbuild-win64-aarch64-msvc%2C%28bmsvc%29&selectedJob=223405437) are failing on the patch for bug 1490496 because "gkrust.lib(mdb.o) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'ARM64'".

INFO - gkrust.lib(mdb.o) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'ARM64'
INFO - z:/build/build/src/config/rules.mk:689: recipe for target 'xul.dll' failed
INFO - mozmake.EXE[4]: *** [xul.dll] Error 1112
INFO - mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/toolkit/library'
INFO - z:/build/build/src/config/recurse.mk:74: recipe for target 'toolkit/library/target' failed
INFO - mozmake.EXE[3]: *** [toolkit/library/target] Error 2
INFO - z:/build/build/src/config/recurse.mk:32: recipe for target 'compile' failed
INFO - mozmake.EXE[2]: *** [compile] Error 2
INFO - z:/build/build/src/config/rules.mk:415: recipe for target 'default' failed
INFO - mozmake.EXE[1]: *** [default] Error 2
INFO - client.mk:125: recipe for target 'build' failed
INFO - mozmake.EXE: *** [build] Error 2
INFO - 366 compiler warnings present.
ERROR - Return code: 2

(https://taskcluster-artifacts.net/dL00xOehSz6WVXVABTEY_g/0/public/logs/live_backing.log)

But the target type looks correct (to my untrained eye) when compiling mdb.c:

INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
…
INFO - [lmdb-sys 0.8.0] running: "cl.exe" "/nologo" "/MD" "/O2" "-w" "/Z7" "/Foz:/build/build/src/obj-firefox\aarch64-pc-windows-msvc\debug\build\lmdb-sys-b0a41784187d4321\out\mdb.o" "/c" "Z:\build\build\src\third_party\rust\lmdb-sys\lmdb\libraries\liblmdb\mdb.c"

Comment 1

[Gabriele Svelto [:gsvelto]]

The mdb.o file is being built using the host (x64) cl.exe compiler, see this line:

00:09:19 INFO - [lmdb-sys 0.8.0] running: "cl.exe" "/nologo" "/MD" "/O2" "-w" "/Z7" "/Foz:/build/build/src/obj-firefox\aarch64-pc-windows-msvc\debug\build\lmdb-sys-b0a41784187d4321\out\mdb.o" "/c" "Z:\build\build\src\third_party\rust\lmdb-sys\lmdb\libraries\liblmdb\mdb.c"

It should be using z:/build/build/src/vs2017_15.9.0p5/VC/bin/Hostx64/arm64/cl.exe instead. Maybe the cross-compiler isn't being passed correctly within that particular crate?

Comment 2

[Nathan Froyd [:froydnj]]

Notice that it's using cl.exe to compile, which means that it's picking up whichever cl is first on $PATH, and not necessarily the cl.exe that is correct for compiling aarch64 code. We get:

00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] HOST = Some("x86_64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] HOST = Some("x86_64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] CC_aarch64-pc-windows-msvc = None
00:09:19 INFO - [lmdb-sys 0.8.0] CC_aarch64_pc_windows_msvc = None
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET_CC = None
00:09:19 INFO - [lmdb-sys 0.8.0] CC = None
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] HOST = Some("x86_64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64-pc-windows-msvc = None
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64_pc_windows_msvc = Some("-w")
00:09:19 INFO - [lmdb-sys 0.8.0] DEBUG = Some("true")
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] HOST = Some("x86_64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64-pc-windows-msvc = None
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64_pc_windows_msvc = Some("-w")
00:09:19 INFO - [lmdb-sys 0.8.0] TARGET = Some("aarch64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] HOST = Some("x86_64-pc-windows-msvc")
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64-pc-windows-msvc = None
00:09:19 INFO - [lmdb-sys 0.8.0] CFLAGS_aarch64_pc_windows_msvc = Some("-w")
00:09:19 INFO - [lmdb-sys 0.8.0] running: "cl.exe" "/nologo" "/MD" "/O2" "-w" "/Z7" "/Foz:/build/build/src/obj-firefox\aarch64-pc-windows-msvc\debug\build\lmdb-sys-b0a41784187d4321\out\mdb.o" "/c" "Z:\build\build\src\third_party\rust\lmdb-sys\lmdb\libraries\liblmdb\mdb.c"

and presumably, since CC_aarch64_pc_windows_msvc is None, the cc crate (?) picks whatever is convenient. I guess we need to figure out how to make it not do that...

Comment 3

[Nathan Froyd [:froydnj]]

One thing you might attempt to do is change:

https://searchfox.org/mozilla-central/source/build/win64-aarch64/mozconfig.vs2017#15

so that ${VSPATH}/VC/bin/Hostx64/arm64 is on the path, and appears before its x64 counterpart. That would presumably let a bare cl.exe pick up the correct cl.exe.

Comment 4

[Mike Hommey [:glandium]]

Except since bug 1409276, compiled initialized by rust build scripts should be using the compiler from the build, and as of bug 1515579, CC/CXX contain the full path to cl.exe, so rust build scripts shouldn't be using a plain cl.exe in the first place.

Comment 5

[Mike Hommey [:glandium]]

Also, tweaking the intree mozconfig is not going to help local builds.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

(In reply to Nathan Froyd [:froydnj] from comment #3)

One thing you might attempt to do is change:

https://searchfox.org/mozilla-central/source/build/win64-aarch64/mozconfig.vs2017#15

so that ${VSPATH}/VC/bin/Hostx64/arm64 is on the path, and appears before its x64 counterpart. That would presumably let a bare cl.exe pick up the correct cl.exe.

That works around the problem, and a CI build then succeeds (https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d817945657f78cf3f00f93d30b8d03c652fd862). It feels pretty hacky, though, and doesn't fix local builds, as glandium notes.

Setting CC_$(rust_cc_env_name)="$(CC)" when running cargo fails (https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba22306e582275a75583dcb5159f28492741b436), presumably because, as the comment in rules.mk notes, "msys path translation makes a mess of the paths":

22:57:45 INFO - running: "z;C:\mozilla-build\msys\build\build\src\sccache2\sccache.exe" "z;C:\mozilla-build\msys\build\build\src\vs2017_15.9.0p5\VC\bin\Hostx64\arm64\cl.exe" "/nologo" "/MD" "/O2" "-w" "/Z7" "/Foz:/build/build/src/obj-firefox\aarch64-pc-windows-msvc\debug\build\lmdb-sys-b0a41784187d4321\out\mdb.o" "/c" "Z:\build\build\src\third_party\rust\lmdb-sys\lmdb\libraries\liblmdb\mdb.c"
22:57:45 INFO - --- stderr
22:57:45 INFO - thread 'main' panicked at '
22:57:45 INFO - Internal error occurred: Failed to find tool. Is cl.exe installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)
22:57:45 INFO - ', Z:\build\build\src\third_party\rust\cc\src\lib.rs:2253:5

Comment 7

[Mike Hommey [:glandium]]

So one of the problems that we have is that currently, the build system can have to deal with 3 build targets, on Windows: the host configure thinks the host is (which currently depends on the bitness of the shell used to run configure), the host cargo/rust think the host is (which depends on the bitness of the rust compiler itself) and the build target.

That's why the current setup is incomplete.

Bug 1522354 brings us one step closer to have only 2, like on other platforms.

Comment 8

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Move rust related rules/setup to a separate makefile.

Because we're going to change how cargo recipes are called to export
environment variables rather than by wrapping the call with env, to
avoid msys roundtrips, it's better to avoid the complexity when not
building rust, and including a separate file only when required helps
with that. It is also possible to wrap the entire rust section of
rules.mk in the same condition we use for the include, but using a
separate file also makes things clearer.

Comment 9

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Move most environment variables we pass to cargo to make exports.

The env program, on windows, comes from msys, so invoking env cargo
guarantees an msys roundtrip, which usually breaks environment variable
in interesting ways.

This moves most of the environment variables we set with env (the
easiest ones) to exporting the same values from make itself.

Depends on D18180

Comment 10

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Move check from bug 1376621 to the RUST_LIBRARY_FILE recipe.

This is a drive-by change, allowing to keep the
force-cargo-library-build recipe more like the others.

Depends on D18181

Comment 11

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Move RUSTFLAGS to per-recipe environment variables.

Depends on D18182

Comment 12

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Move remaining cargo environment variable settings to recipes.

These require some awkward setup to keep things working on
non-cross-compiles on non-Windows, but we'll change that shortly in a
later bug.

Depends on D18183

Comment 13

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Replace double quotes with single quotes.

Double quotes on a command line forces Make to use a msys shell when
invoking the command. Single quotes don't have this effect. This is the
last bit that prevented Make from invoking cargo directly on Windows.

Depends on D18184

Comment 14

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Patch cc-rs to handle aarch64 with clang-cl.

This backports https://github.com/alexcrichton/cc-rs/pull/370 to the
version of cc-rs we currently have in tree, to minimize the changes.

Depends on D18185

Comment 15

[Mike Hommey [:glandium]]

Attachment: Bug 1522614 - Pass CC/CXX/CFLAGS/CXXFLAGS/AR down to cargo on Windows.

Now that Make invokes cargo without going through an msys shell,
environment variables are going to be preserved properly, and we can now
"safely" pass the compiler-related variables down to cargo on Windows.

This makes rust target builds use the expected compiler and flags,
instead of the cc-rs crate guessing, picking cl.exe, and using the wrong
one, with the build later failing when linking it all together because
one of the objects is not for the right target.

Interestingly, the lmdb code is today built for the wrong target on
aarch64, but somehow, it doesn't break the build on automation,
presumably because the lmdb code is actually dead code, and the linker
eliminates the object as unused, masking the problem.

Depends on D18186

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b06dcb87f2a
Move rust related rules/setup to a separate makefile. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/5d4ea8ef4184
Move most environment variables we pass to cargo to make exports. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/a48700da5d3d
Move check from bug 1376621 to the RUST_LIBRARY_FILE recipe. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/0fb52008136b
Move RUSTFLAGS to per-recipe environment variables. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/a3ea95f426ca
Move remaining cargo environment variable settings to recipes. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/acd8ed237c7f
Replace double quotes with single quotes. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/06b6f5ce09bc
Patch cc-rs to handle aarch64 with clang-cl. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/e4074649d75f
Pass CC/CXX/CFLAGS/CXXFLAGS/AR down to cargo on Windows. r=froydnj

Comment 17

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/0b06dcb87f2a
https://hg.mozilla.org/mozilla-central/rev/5d4ea8ef4184
https://hg.mozilla.org/mozilla-central/rev/a48700da5d3d
https://hg.mozilla.org/mozilla-central/rev/0fb52008136b
https://hg.mozilla.org/mozilla-central/rev/a3ea95f426ca
https://hg.mozilla.org/mozilla-central/rev/acd8ed237c7f
https://hg.mozilla.org/mozilla-central/rev/06b6f5ce09bc
https://hg.mozilla.org/mozilla-central/rev/e4074649d75f