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

RESOLVED FIXED in Firefox 67

Status

defect
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: myk, Assigned: glandium)

Tracking

unspecified
mozilla67
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(8 attachments)

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"

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?

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

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.

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.

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

(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

Assignee: nobody → mh+mozilla

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.

Depends on: 1522354
Depends on: 1523143
Depends on: 1523203
Depends on: 1523540
Blocks: 1522609
See Also: → 1522609
Depends on: 1524186

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.

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

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

Depends on D18181

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

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

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

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

Blocks: 1524396
Pushed by mh@glandium.org:
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
Duplicate of this bug: 1399882
You need to log in before you can comment on or make changes to this bug.