appveyor: Downgrade MinGW to 6.2.0
It looks like the 6.3.0 MinGW comes with a gdb which has issues (#40184) that an attempted workaround (#40777) does not actually fix (#40835). The original motivation for upgradin MinGW was to fix build flakiness (#40546) due to newer builds not exhibiting the same bug, so let's hope that 6.2.0 isn't too far back in time and still contains the fix we need. Closes #40835
This commit is contained in:
parent
ccce2c6eb9
commit
e87dd42cfe
2 changed files with 6 additions and 22 deletions
|
@ -46,13 +46,13 @@ environment:
|
|||
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja
|
||||
SCRIPT: python x.py test
|
||||
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
|
||||
MINGW_ARCHIVE: i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z
|
||||
MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z
|
||||
MINGW_DIR: mingw32
|
||||
- MSYS_BITS: 64
|
||||
SCRIPT: python x.py test
|
||||
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja
|
||||
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
|
||||
MINGW_ARCHIVE: x86_64-6.3.0-release-win32-seh-rt_v5-rev1.7z
|
||||
MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z
|
||||
MINGW_DIR: mingw64
|
||||
|
||||
# 32/64 bit MSVC and GNU deployment
|
||||
|
@ -71,14 +71,14 @@ environment:
|
|||
RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-extended --enable-ninja
|
||||
SCRIPT: python x.py dist
|
||||
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
|
||||
MINGW_ARCHIVE: i686-6.3.0-release-win32-dwarf-rt_v5-rev1.7z
|
||||
MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z
|
||||
MINGW_DIR: mingw32
|
||||
DEPLOY: 1
|
||||
- MSYS_BITS: 64
|
||||
SCRIPT: python x.py dist
|
||||
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-extended --enable-ninja
|
||||
MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror
|
||||
MINGW_ARCHIVE: x86_64-6.3.0-release-win32-seh-rt_v5-rev1.7z
|
||||
MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z
|
||||
MINGW_DIR: mingw64
|
||||
DEPLOY: 1
|
||||
|
||||
|
|
|
@ -58,24 +58,8 @@ pub fn run(lib_path: &str,
|
|||
let mut cmd = Command::new(prog);
|
||||
cmd.args(args)
|
||||
.stdout(Stdio::piped())
|
||||
.stderr(Stdio::piped());
|
||||
|
||||
// Why oh why do we sometimes make a pipe and sometimes inherit the stdin
|
||||
// stream, well that's an excellent question! In theory it should suffice to
|
||||
// always create a pipe here and be done with it. Unfortunately though
|
||||
// there's apparently something odd with the gdb that comes with gcc 6.3.0
|
||||
// on MinGW. Tracked at rust-lang/rust#40184 when stdin is piped here
|
||||
// (unconditionally) then all gdb tests will fail on MinGW when using gcc
|
||||
// 6.3.0. WHen using an inherited stdin though they happen to all work!
|
||||
//
|
||||
// As to why this fixes the issue, well, I have no idea. If you can remove
|
||||
// this branch and unconditionally use `piped` and it gets past @bors please
|
||||
// feel free to send a PR!
|
||||
if input.is_some() || !cfg!(windows) {
|
||||
cmd.stdin(Stdio::piped());
|
||||
} else {
|
||||
cmd.stdin(Stdio::inherit());
|
||||
}
|
||||
.stderr(Stdio::piped())
|
||||
.stdin(Stdio::piped());
|
||||
|
||||
add_target_env(&mut cmd, lib_path, aux_path);
|
||||
for (key, val) in env {
|
||||
|
|
Loading…
Add table
Reference in a new issue