Windows builds fail to link C++ static library

[jdm]

Code

Building the mozjs crate for any Windows target stopped working after #97485. mozjs has a build script that compiles the C++ library SpiderMonkey into js_static.a, which is then linked. Before #97485, these builds worked successfully. Since that PR was merged, CI using nightly and beta toolsets targeting MSVC x86_64 and UWP x86_64 now fail to build with the following error:

error: failed to add native library D:\a\mozjs\mozjs\target\debug\build\mozjs_sys-4062d5cd7cbc7110\out\build/js/src/build\js_static.lib: Unsupported archive identifier

This was first reported in servo/mozjs#327 and servo/mozjs#334.

Version it worked on

2022-12-03 nightly
Rust 1.66 beta

Version with regression

2022-12-04 nightly
Rust 1.67 beta

If you know when this regression occurred, please add a line like below, replacing {channel} with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[jyn514]

cc @bjorn3

[bjorn3]

As workaround adding windows to

rust/compiler/rustc_codegen_llvm/src/back/archive.rs

Line 105 in 85da15c

if sess.target.arch == "wasm32" || sess.target.arch == "wasm64" {

should revert back to the old archive writer. Luckily it was preserved for wasm.

Could you post a hex dump of the first 16 or so bytes of the js_static.lib archive to see the magic bytes of this file.

[sagudev]

Here is hexdump:

0000000 3c21 6874 6e69 0a3e 202f 2020 2020 2020
0000010 2020 2020 2020 2020 2030 2020 2020 2020

Here is GitHub action of working one: https://github.com/sagudev/mozjs/actions/runs/3974783209 and here is GitHub action of defect one: https://github.com/sagudev/mozjs/actions/runs/3974683394. Artifact contains .lib file, that is produced in windows job.

[bjorn3]

Yeah, that is indeed very much not a valid archive.

┌────────┬─────────────────────────┬────────┐
│00000000│ 3c 21 68 74 6e 69 0a 3e │<!htni_>│
│00000008│ 20 2f 20 20 20 20 20 20 │ /      │
│00000010│ 20 20 20 20 20 20 20 20 │        │
│00000018│ 20 30 20 20 20 20 20 20 │ 0      │
└────────┴─────────────────────────┴────────┘

It does look like !<thin>\n (which is a valid header for thin archives) except with every pair of bytes swapped. Rustc also shouldn't be producing thin archives.

[sagudev]

Well hex-editor in vscode shows it right (but hexdump is showing reversed bits on same file):

[mati865]

Do you know if this affects all Windows targets or just MSVC based?
I couldn't get it to build at all with windows-gnu:

$ LANG=C.utf8 cargo t
   Compiling mozjs_sys v0.68.2 (D:\tmp\mozjs\mozjs)
error: failed to run custom build command for `mozjs_sys v0.68.2 (D:\tmp\mozjs\mozjs)`

Caused by:
  process didn't exit successfully: `D:\tmp\mozjs\target\debug\build\mozjs_sys-352d87b28c39ffac\build-script-build` (exit code: 101)
  --- stdout
  cargo:outdir=D:\tmp\mozjs\target\debug\build\mozjs_sys-27c0928751302e7b\out\build

  --- stderr
  make: invalid --jobserver-auth string '__rust_jobserver_semaphore_2019855554'
  make: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
  D:\tmp\mozjs\mozjs\makefile.cargo:175: *** recipe commences before first target.  Stop.
  thread 'main' panicked at 'assertion failed: result.success()', mozjs\build.rs:178:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[sagudev]

Ideally we would want to find another case for regression, because mozjs is complicated.
@mati865 Do you have MozillaBuild 3.4 installed as error is in makefile.cargo:175 and MozBuild comes packaged with python? I suggest looking at GitHub Workflows to correctly setup for compiling.

[mati865]

@mati865 Do you have MozillaBuild 3.4 installed as error is in makefile.cargo:175 and MozBuild comes packaged with python?

No, I had checked first step in the readme but the link is dead:

Follow the directions at https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites