Closed alepez closed 6 months ago
This issue needs an in-depth analysis. For now, I disable the affected platform.
I decided to look into this myself, and it seems to run far deeper than Lavagna. I'm starting to get very surprised that nobody else has encountered this.
I can reproduce it with a minimal working example: https://github.com/patowen/lavagna/tree/broken-build-script (See https://github.com/patowen/lavagna/pull/1 for the failing workflows, although that link is less reliable).
Since I may delete my fork at some point, I'll list out the minimal reproducible example here:
.github\workflows\ci.yml:
name: ci
on:
workflow_dispatch:
pull_request:
push:
branches:
- main
schedule:
- cron: '00 01 * * *'
jobs:
build:
name: build
env:
# Emit backtraces on panics.
RUST_BACKTRACE: 1
CARGO_INCREMENTAL: 0
runs-on: windows-2019
strategy:
fail-fast: false
matrix:
rust_version:
- stable
- beta
- nightly
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Install Rust
uses: actions-rs/toolchain@v1
with:
toolchain: ${{ matrix.rust_version }}-x86_64-pc-windows-gnu
target: x86_64-pc-windows-gnu
profile: minimal
override: true
- name: Build
shell: bash
run: cargo build --verbose --target x86_64-pc-windows-gnu
src\main.rs:
fn main() {
println!("Hello world");
}
build.rs:
fn main() {
println!("I am in a build script.");
}
Cargo.lock:
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
version = 3
[[package]]
name = "proc-macro2-testing-for-lavagna"
version = "0.1.0"
Cargo.toml:
[package]
name = "proc-macro2-testing-for-lavagna"
version = "0.1.0"
edition = "2021"
Result of "Build" step on beta branch:
Run cargo build --verbose --target x86_64-pc-windows-gnu
Compiling proc-macro2-testing-for-lavagna v0.1.0 (D:\a\lavagna\lavagna)
Running `rustc --crate-name build_script_build --edition=2021 build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=b191affa0bd3624f -C extra-filename=-b191affa0bd3624f --out-dir 'D:\a\lavagna\lavagna\target\debug\build\proc-macro2-testing-for-lavagna-b191affa0bd3624f' -L 'dependency=D:\a\lavagna\lavagna\target\debug\deps'`
Running `D:\a\lavagna\lavagna\target\debug\build\proc-macro2-testing-for-lavagna-b191affa0bd3624f\build-script-build`
error: failed to run custom build command for `proc-macro2-testing-for-lavagna v0.1.0 (D:\a\lavagna\lavagna)`
Caused by:
process didn't exit successfully: `D:\a\lavagna\lavagna\target\debug\build\proc-macro2-testing-for-lavagna-b191affa0bd3624f\build-script-build` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)
Error: Process completed with exit code 101.
I haven't been able to reproduce the error locally, so it seems specific to GitHub actions, possibly some configuration it uses. I tried building the minimal example with a bunch of different nightly versions on GitHub, and it seems like nightly-2024-02-26 (also known as 1.78.0-nightly (0ecbd0605 2024-02-25)) is the last good version, and nightly-2024-02-27 (also known as 1.78.0-nightly (fc3800f65 2024-02-26)) is the first bad version.
Unfortunately, it isn't as simple as checking the comparison because it's huge, and nothing seems to mention GNU (https://github.com/rust-lang/rust/compare/0ecbd0605..fc3800f65).
The only thing I've found so far that could be even semi-related is the addition of #[cfg(target_vendor = "win7")]
in library/std/src/sys/pal/windows/compat.rs
(which I found by searching for "entry"). Those changes come from https://github.com/rust-lang/rust/pull/121317, which did seem to cause a cross compilation bug, but there's good reason to believe it's unrelated. It's probably worth just filing a bug in https://github.com/rust-lang/rust/issues and seeing if anyone more familiar with Rust finds anything.
Interestingly, using Windows Server 2022 instead of 2019 seems to fix the issue.
I asked in Zulip in case anyone has any better ideas, but there does seem to be an effective workaround now. Perhaps I would have been able to reproduce this locally if I owned a copy of Windows Server 2019.
It seems like the root cause was that the Windows 2019 version on GitHub Actions has an outdated version of MinGW, and changes were made to rustc
that were incompatible with that outdated version. This compatibility has been restored in the latest nightly release (2024-04-19).
I believe any of the following actions will resolve this issue with lavagna:
os: windows-2022
instead of os: windows-2019
in ci.yml
windows-2019
to use a different version of gcc
(likely the most work for little benefit)Now that simply waiting will likely resolve this issue, I think it's safe to ignore it for now.
I mainly took the time to investigate this because I'm thankful that this project was made and wanted to try to help out where I could on the (likely) more annoying aspects of maintaining it.
Nice catch! I'm trying with windows-2022 right now, which seems to be the quickest fix possible.
Check this github actions run: https://github.com/alepez/lavagna/actions/runs/8694841480/job/23844594711
It fails with this errors: