-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incompatibility between rustc's libgcc_s_dw2-1.dll and MSYS2 mingw-w64-i686-gcc 11.3 #99534
Comments
Does it still happen with up-to-date MSYS2 and nightly recent enough to include #100178 ? |
The bug seems to be fixed on 1.69.0-beta.3 which does include #100178. |
ChrisDenton
added
the
needs-triage-legacy
Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged.
label
Jul 16, 2023
Noratrieb
added
O-x86_32
Target: x86 processors, 32 bit (like i686-*)
and removed
O-x86-all
labels
Oct 25, 2023
ChrisDenton
removed
the
needs-triage-legacy
Old issue that were never triaged. Remove this label once the issue has been sufficiently triaged.
label
Aug 8, 2024
Thanks! Closing as fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the stable-i686-pc-windows-gnu toolchain's bin directory is at the beginning of the PATH variable (as will happen when using rustup), MSYS2 x86 gcc versions 11.3 and higher fail.
This can be reproduced
on the MSYS2 MinGW x86 terminal
install mingw-w64-i686-gcc package version 11.3 or higher (I tested with 11.3.0-2)
include the toolchain's bin directory at the beginning of the PATH, for example with
try to compile a simple c file, for example
gcc a.c
with a.c containing onlyint main () { return 0; }
No a.exe is generated. Repeating with gcc version 11.2 (I tested with 11.2.0-9) will generate a.exe.
With the latest MSYS2 gcc (12.1.0-3) the problem is still there with no a.exe generated.
If libgcc_s_dw2-1.dll is removed from the toolchain's bin directory, a.exe is generated.
(I first thought it was a rustup 1.25 issue and opened rust-lang/rustup#3045, but then I realized the issue is here, or maybe in MSYS2/gcc.)
The text was updated successfully, but these errors were encountered: