Nothing builds under latest nightly release on windows #25072
Labels
O-windows
Operating system: Windows
Comments
|
I can reproduce this, but only if I invoke "rustc" from 32-bit versions of cygwin or msys2/mingw. If I run it via windows cmd, or the 64-bit versions it works fine. edit: |
|
Appveyor builds of official crates have been failing because of this issue, for example: https://ci.appveyor.com/project/alexcrichton/time It's a regression, as it used to work until last week or so: https://ci.appveyor.com/project/alexcrichton/time/history |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 4, 2015
This was one last spot where directories were being leaked through with arguments of the form `\\?\` which neither `ld.exe` nor `gcc.exe` does understands so the prefix needed to be stripped. Closes rust-lang#25072
bors
added a commit
that referenced
this issue
May 4, 2015
This was one last spot where directories were being leaked through with arguments of the form `\\?\` which neither `ld.exe` nor `gcc.exe` does understands so the prefix needed to be stripped. Closes #25072
|
Tested this issue on and I still get the above reported issue with this project. Waiting for latest nightly build to test and see if it works there. My version of the error log: |
|
For the record I am using a locally built Rust and I do not get the error. Therefore this bug may be a symptom of the way the nightlies are being packaged. |
|
@retep998 Maybe this doesn't happen if you have MinGW installed separately. |
|
Yep, it seems it is the bundled MinGW that is broken If I install that nightly with the bundled MinGW and invoke it from |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 5, 2015
Turns out that a verbatim path was leaking through to gcc via the PATH environment variable (pointing to the bundled gcc provided by the main distribution) which was wreaking havoc when gcc itself was run. The fix here is to just stop passing verbatim paths down by adding more liberal uses of `fix_windows_verbatim_for_gcc`. Closes rust-lang#25072
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 5, 2015
Turns out that a verbatim path was leaking through to gcc via the PATH environment variable (pointing to the bundled gcc provided by the main distribution) which was wreaking havoc when gcc itself was run. The fix here is to just stop passing verbatim paths down by adding more liberal uses of `fix_windows_verbatim_for_gcc`. Closes rust-lang#25072
bors
added a commit
that referenced
this issue
May 6, 2015
…rson Turns out that a verbatim path was leaking through to gcc via the PATH environment variable (pointing to the bundled gcc provided by the main distribution) which was wreaking havoc when gcc itself was run. The fix here is to just stop passing verbatim paths down by adding more liberal uses of `fix_windows_verbatim_for_gcc`. Closes #25072
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Whatever the code being compiled,
ldcomplains about not finding crt2.o, crtbegin.o, and crtend.o, even though these files should all be found by GCC, and is so on beta.As can be seen in the log, the
crtfiles are not found, even though the"-L" "C:\Program Files\Rust nightly\bin\rustlib\x86_64-pc-windows-gnu\lib"option is set for gcc, and the files do exist:I'm even more confused by the fact that everything works fine on rust beta, even though the setup is the same.
edit: I am running this with 64-bit versions of rust nightly and rust beta
The text was updated successfully, but these errors were encountered: