Windows 32 bits nightlies fail to compile a simple hello world

[tomaka]

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: rustc 0.12.0-pre-nightly (ccae356ac 2014-09-12 23:30:54 +0000)

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 #13501 (comment)

cargo new test --bin
cd test
cargo build

Fails with:

error: linking with `gcc` failed: exit code: 1
note: gcc '-m32' '-L' 'C:\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib' '-o'
 'C:\Users\Tomaka17\Projets\test\target\test.exe' 'C:\Users\Tomaka17\Projets\tes
t\target\test.o' '-Wl,--whole-archive' '-lmorestack' '-Wl,--no-whole-archive' '-
fno-lto' '-fno-use-linker-plugin' '-Wl,--gc-sections' '-shared-libgcc' '-Wl,--en
able-long-section-names' '-Wl,--nxcompat' '-Wl,--dynamicbase' '-Wl,--large-addre
ss-aware' 'C:\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\libnative-4e7c5e5
c.rlib' 'C:\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\libstd-4e7c5e5c.rli
b' 'C:\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\libsync-4e7c5e5c.rlib' '
C:\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\librustrt-4e7c5e5c.rlib' 'C:
\Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\librand-4e7c5e5c.rlib' 'C:\Com
pilation\Rust\bin\rustlib\i686-pc-mingw32\lib\libcollections-4e7c5e5c.rlib' 'C:\
Compilation\Rust\bin\rustlib\i686-pc-mingw32\lib\libunicode-4e7c5e5c.rlib' 'C:\C
ompilation\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-4e7c5e5c.rlib' 'C:\Comp
ilation\Rust\bin\rustlib\i686-pc-mingw32\lib\liblibc-4e7c5e5c.rlib' 'C:\Compilat
ion\Rust\bin\rustlib\i686-pc-mingw32\lib\libcore-4e7c5e5c.rlib' '-L' 'C:\Users\T
omaka17\Projets\test\target' '-L' 'C:\Users\Tomaka17\Projets\test\target\deps' '
-L' 'C:\Users\Tomaka17\Projets\test\.rust' '-L' 'C:\Users\Tomaka17\Projets\test'
 '-L' 'C:\Users\Tomaka17\.rust' '-Wl,--whole-archive' '-Wl,-Bstatic' '-Wl,--no-w
hole-archive' '-Wl,-Bdynamic' '-lws2_32' '-lgcc_s' '-lcompiler-rt'
note: c:/compilation/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/
crt2.o: In function `_mingw_CRTStartup':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/crt1.c:217: undefined reference to `__cpu_features_init'
c:/compilation/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o
: In function `mingw32_init_mainargs':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:260: undefined reference to `_CRT_glob'
c:/compilation/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o
: In function `_mingw_setargv':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:120: undefined reference to `_CRT_glob'
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:155: undefined reference to `_CRT_glob'
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:241: undefined reference to `__mingw_glob'
c:/compilation/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o
: In function `mingw32_init_fmode':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/crt1.c:84: undefined reference to `_CRT_fmode'
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/crt1.c:101: undefined reference to `_CRT_fmode'
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/crt1.c:105: undefined reference to `_CRT_fmode'
c:/compilation/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o
: In function `_mingw_setargv':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:214: undefined reference to `__mingw_glob'
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src
/src/libcrt/crt/init.c:186: undefined reference to `_CRT_glob'
collect2.exe: error: ld returned 1 exit status

error: aborting due to previous error
Could not compile `test`.

To learn more, run the command again with --verbose.

[retep998]

cc @vadimcn

[vadimcn]

@tomaka, which mingw distribution are you on? Can you please paste the output of gcc --version?
Please note that if mingw is on the path, it takes precedence over the packaged version.

[tomaka]

gcc --version only gives me gcc (GCC) 4.8.1
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.

[vadimcn]

Hmm, I see... So you are using mingw32, while we've bundled platform libraries from mingw-w64, and because rustc adds rustlib//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.

[vadimcn]

@tomaka: 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.

[tomaka]

Removing MinGW32 from my $PATH fixed it.
I guess I'll close this then, thanks.

[brson]

@vadimcn Might we prepend the search paths instead to fix this issue?

[vadimcn]

@brson, 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/.

[ghost]

@vadimcn, 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 PATH for always using the bundled binaries will fix all these issues.

[vadimcn]

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.
@brson, any thoughts about this?

[tomaka]

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.

I encountered this problem in one of my repositories where I use the win32 API. I plan to add the libgdi32.lib and libopengl32.a 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.

[ghost]

@vadimcn, 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 rustc --mingw 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 cargo update --gcc-libs or whatever is planned for downloading libs in cargo 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 @tomaka said above , as we can just add the gcc-libs dependency to the Cargo.toml 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 emphasis on 's' in libs we actually require from the package , maybe something like cargo update --gcc-libs=libgdi32.lib , 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.

[brson]

@vadimcn 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.

[brson]

The fix for this was reverted.

[vadimcn]

Nah, this should stay closed. Alex only reverted commit which made rust prefer bundled gcc.

[alexcrichton]

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 @vadimcn!). Right now we'll just fall back to the bundled gcc if one isn't available elsewhere.