Change:
trans: &CrateTranslation, outputs: &OutputFilenames) { let old_path = os::getenv("PATH").unwrap_or_else(||String::new()); <del> let mut new_path = os::split_paths(old_path.as_slice()); new_path.push_all_move(sess.host_filesearch().get_tools_search_paths()); </del> <ins> let mut new_path = sess.host_filesearch().get_tools_search_paths(); new_path.push_all_move(os::split_paths(old_path.as_slice())); </ins> os::setenv("PATH", os::join_paths(new_path.as_slice()).unwrap()); time(sess.time_passes(), "linking", (), |_|

Discussion:
This is probably due to the fact that MinGW is now packaged in rustc. These are the first nightlies where this is the case. Version: Note: This is on the 32 bits nightlies. It may also happen in the 64 bits nightlies, but I couldn't test it because of Fails with:
cc
which mingw distribution are you on? Can you please paste the output of ? Please note that if mingw is on the path, it takes precedence over the packaged version.
only gives me I don't know how to check the mingw distribution, I installed it probably more than a year ago and don't remember. I have been downloading the nightlies almost every day for at least the past two months, and it suddenly breaks the day where MinGW is packaged with rustc.
Hmm, I see... So you are using mingw32, while we've bundled platform libraries from mingw-w64, and because rustc adds rustlib/<triple/lib to the library search path, gcc ends up finding mingw-w64 ones before mingw32's. And mingw-w64 libs don't define some of the symbols that mingw32's startup files expect.
I'm kinda surprised it worked before for you. After I deleted the bundled gcc and libs, my builds are still failing because librustrt references function _mktime32, which is apparently absent in mingw32.
Removing MinGW32 from my $PATH fixed it. I guess I'll close this then, thanks.
Might we prepend the search paths instead to fix this issue?
if we prepend, we'll be always using the bundled gcc binaries. I am not sure that's desirable. I'll try moving out gcc and its libs into a separate directory under rustlib/<triple.
won't it be better to use the bundled gcc binaries. I mean some people might be using outdated or incompatible mingw/gcc, which will surely give lots of errors. Using hardcoded paths instead of searching for always using the bundled binaries will fix all these issues.
Good point. On the flip side, though, there may be cases when using a separately installed toolchain is desirable. For example, we don't bundle import libraries for most of the Windows dlls, so in order to call them one would have to use a full mingw installation. any thoughts about this?

I encountered this problem in where I use the win32 API. I plan to add the and files in the repository because I think that rust should be as distinct as possible from MinGW, and I don't want the user to install MinGW just for my crate.
well i guess you are right. But there are a lot of programs that won't require those libs. So isn't it possible to have something like - The compiler has the defaults to use the included gcc. When we require other libs then we can pass an option to the compiler for it, so that it searches the path for a gcc. Because there will be many people who are just learning and/or do not require those libs. So the included gcc will be enough for them, and it won't create confusions. And for those who require those libs, they can pass an option to the compiler, something like,maybe or probably something better. I think this will reduce the problems that are occuring as of now. And it shouldn't create any more problems because the included gcc location will be hardcoded, so there won't be any need to have that directory on PATH, and when we pass the option to the compiler and it searches the PATH, there will only be the path for MinGW's gcc so there won't be any confusion and the gcc from MINGW will be used. And maybe, by the time Rust reaches 1.0 Final Release build , sometime mid-2015 , there might not be the need to include gcc, as lld might become better. But...... I think that this might complicate some stuff . Or rather , you could just upload all the libs somewhere , maybe to the upcoming Cargo-Central-Repository and an option like or or something even better so that it downloads all the libs and puts it in with the other included gcc stuff . That will fix what said above , as we can just add the dependency to the file making everything pretty-simple. And that would not complicate the stuff. And then you could just hardcode the gcc path as MinGW won't be required anymore. And if you plan this, then it would be better to have a way to download and specify exactly which libs we actually require from the package , maybe something like , also something which does this for the TOML file. This would be a better idea, as Cargo would be a necessity in the near future.

I think in the short term, I prefer the reliability of always using the bundled toolchain. Those that don't want that can potentially rebuild from source.
The fix for this was reverted.
Nah, this should stay closed. Alex only reverted commit which made rust prefer bundled gcc.
Ah yes, I also think this is still fixed in that we no longer have the bundled gcc libs in the link path by default (thanks Right now we'll just fall back to the bundled gcc if one isn't available elsewhere.