Change:
self } <ins> /// Like `obj_to_ar` except creating a thin archive. pub fn obj_to_thin_ar(&mut self) -> &mut Self { self.cmd.arg("rcus").arg("--thin"); self } </ins> /// Extract archive members back to files. pub fn extract(&mut self) -> &mut Self { self.cmd.arg("x");

Discussion:
Building the mozjs crate for any Windows target stopped working after mozjs has a build script that compiles the C++ library SpiderMonkey into , which is then . Before , these builds worked successfully. Since that PR was merged, CI using nightly and beta toolsets targeting MSVC x8664 and UWP x86_64 now fail to build with the following error: This was first reported in and 2022-12-03 nightly Rust 1.66 beta 2022-12-04 nightly Rust 1.67 beta If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged
cc
As workaround adding windows to 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 archive to see the magic bytes of this file.
Here is hexdump: Here is GitHub action of working one: and here is GitHub action of defect one: Artifact contains .lib file, that is produced in job.
Yeah, that is indeed very much not a valid archive. It does look like (which is a valid header for thin archives) except with every pair of bytes swapped. Rustc also shouldn't be producing thin archives.
Well hex-editor in vscode shows it right (but is showing reversed bits on same file): !
Do you know if this affects all Windows targets or just MSVC based? I couldn't get it to build at all with :
Ideally we would want to find another case for regression, because mozjs is complicated. Do you have MozillaBuild 3.4 installed as error is in and MozBuild comes packaged with python? I suggest looking at GitHub Workflows to correctly setup for compiling.
No, I had checked first step in the readme but the link is dead:
Well, those instruction would not be relevant anymore as we are still few SM versions behind if they would be available. Following GitHub Workflows is currently the best way.
WG-prioritization assigning priority (). label -I-prioritize +P-high
label: -P-high +P-critical (Upgrading priority because, until we better understand the scope of this bug, it strikes me as something that might motivate a fast-tracked point release for 1.67.)

I wonder if we have another case of this issue in
You linked this issue itself.
Could be
Oh, I completely misunderstood what the issue was. I thought this was about rustc producing a malformed archive, but it is actually about rustc not being able to read thin archives produced by an external build system. Object indeed doesn't support parsing thin archives and even if it did, it would likely need to be wired up in rustc separately. I think the best course of action is to change to always take the branch. This will restore the old behavior for cg_llvm. will probably also need to be reverted partially or as a whole because it removed macOS fat archive reading for the LLVM archive writer. (This would have been so much more painful to revert if I hadn't needed to keep the old LLVM archive writer for wasm.)
And yes is very likely a duplicate of this.
I believe I may be encountering a similar, or related, regression between 1.67 and 1.66 when attempting to build and link against shaderc on MSVC:
I know it's a little late for clarification now, but still. (GitHub Actions) build has the same header as non-working build; and that .lib file is built by SM build scripts not Rust ( dir is SM out directory). The main misunderstanding comes from weird behavior:
Opened to revert back to LlvmArchiveWriter, which would fix this issue for now I think.
label: E-needs-test
(and any such test should probably be beta-backported; see discussion from )
Downgrading to as we've shipped a point release with this fix. Leaving open as we would love a regression test to be .
Untagging as a regression, since this has been fixed on beta + stable + nightly at this point as far as I can tell.