appveyor: Upgrade to gcc for mingw 6.3.0 #41420
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
shepmaster
added
the
S-waiting-on-review
|
Thanks for the PR, @alexcrichton! We'll rustle up a review from @brson for you! |
|
@alexcrichton: Can you upload the respective posix threads versions as well? |
|
@TimNN already done :) I actually thought we had already upgraded and when I got around to actually making a PR I noticed I didn't have to... We should have win32/pthread 6.2.0/6.3.0 all uploaded |
|
☔ The latest upstream changes (presumably #40123) made this pull request unmergeable. Please resolve the merge conflicts. |
alexcrichton
force-pushed
the
mingw-6.3.0
branch
from
dfec154
to
3b33913
Compare
|
Updated |
|
@bors r+ |
|
📌 Commit 3b33913 has been approved by |
arielb1
added
S-waiting-on-bors
|
@bors: p=1 (hopefully fixing a lot of spurious failures with this) |
…enkov appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes rust-lang#40546
|
⌛ Testing commit 3b33913 with merge 9a8b446... |
|
💔 Test failed - status-appveyor |
|
Non-spurious failure. @alexcrichton said on IRC that they probably forgot to upload artifacts. |
alexcrichton
force-pushed
the
mingw-6.3.0
branch
from
3b33913
to
d7d2e5c
Compare
|
@bors: r=petrochenkov |
|
📌 Commit d7d2e5c has been approved by |
|
⌛ Testing commit d7d2e5c with merge 690233d... |
|
💔 Test failed - status-appveyor |
alexcrichton
force-pushed
the
mingw-6.3.0
branch
from
d7d2e5c
to
e239e47
Compare
|
@bors: r=petrochenkov |
|
📌 Commit e239e47 has been approved by |
|
⌛ Testing commit e239e47 with merge e28a4f6... |
|
💔 Test failed - status-appveyor |
|
Legitimate failure: |
Mark-Simulacrum
added
S-waiting-on-author
appveyor.yml
Outdated
| # Note that we don't literally overwrite the gdb.exe binary because it appears | ||
| # to just use gdborig.exe, so that's the binary we deal with instead. | ||
| - if defined MINGW_URL appveyor-retry appveyor DownloadFile %MINGW_URL%/2017-04-20-%MSYS_BITS%bit-gdborig.exe | ||
| - if defined MINGW_URL mv 2017-04-20-%MSYS_BITS%bits-gdborig.exe %MINGW_DIR%\bin\gdborig.exe |
There was a problem hiding this comment.
bits needs to be bit here.
This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes rust-lang#40546
alexcrichton
force-pushed
the
mingw-6.3.0
branch
from
e239e47
to
d1db74b
Compare
|
@bors: r=petrochenkov I sure wish there was like an |
|
📌 Commit d1db74b has been approved by |
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
|
Homu's having trouble, but tests passed, so merging |
This commit sort of brings back #40777 by upgrading back to 6.3.0. While
investigating #40546 it was discovered that 6.3.0 appears to not spurious
fail in the same way that 6.2.0 does (which we're currently using). The
workaround for #40184 contained in #40777 did not work so this commit also
contains a different workaround for the gdb issue. We will not download the
6.2.0 version of gdb and use that instead of the default version that comes with
6.3.0.
I'm going to optimistically say...
Closes #40546