Cannot run any rust programs on windows

[DarthShoge]

I was following the getting started https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust process and I had managed to write the simple hello world program and compiled it succesfully with mysys. the problem is that when i try to run it crashes instantly with ntdll.dll being at fault (note this is with g++ 4.8) when i run with the recomended g++ version 4.5 it wont even comiple i end up getting this outputted

error: linking with `gcc` failed: exit code: 1
note: gcc '-m32' '-L' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib' '-o' 'hello' 'hello.o' '-lmorestack' '-Wl,--gc-sections' '-shared-libgcc' '-Wl,--enable-long-section-names' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libnative-1fb5e2c0-0.11.0-pre.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libstd-59beb4f7-0.11.0-pre.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libcore-c5ed6fb4-0.11.0-pre.rlib' 'C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liblibc-4f9a876d-0.11.0-pre.rlib' '-L' 'C:\Users\Admin\rust\.rust' '-L' 'C:\Users\Admin\rust' '-Wl,-Bdynamic' '-lws2_32' '-lgcc_s' '-lcompiler-rt'
note: C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libstd-59beb4f7-0.11.0-pre.rlib(r-rustrt-rust_builtin.o): In function `gmtime':
c:/program files (x86)/mingw-builds/x32-4.8.1-win32-dwarf-rev5/mingw32/i686-w64-mingw32/include/time.h:240: undefined reference to `_gmtime32'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libstd-59beb4f7-0.11.0-pre.rlib(r-rustrt-rust_builtin.o): In function `localtime':
c:/program files (x86)/mingw-builds/x32-4.8.1-win32-dwarf-rev5/mingw32/i686-w64-mingw32/include/time.h:238: undefined reference to `_localtime32'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\libstd-59beb4f7-0.11.0-pre.rlib(r-rustrt-rust_builtin.o): In function `mktime':
c:/program files (x86)/mingw-builds/x32-4.8.1-win32-dwarf-rev5/mingw32/i686-w64-mingw32/include/time.h:239: undefined reference to `_mktime32'
c:/program files (x86)/mingw-builds/x32-4.8.1-win32-dwarf-rev5/mingw32/i686-w64-mingw32/include/time.h:239: undefined reference to `_mktime32'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-stats.o):stats.c:(.text+0x2313): undefined reference to `__chkstk_ms'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-stats.o):stats.c:(.text+0x309f): undefined reference to `__chkstk_ms'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-util.o):util.c:(.text+0x2079): undefined reference to `__chkstk_ms'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-ctl.o):ctl.c:(.text+0x2945): undefined reference to `__chkstk_ms'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-ctl.o):ctl.c:(.text+0x493f): undefined reference to `__chkstk_ms'
C:\Program Files (x86)\Rust\bin\rustlib\i686-pc-mingw32\lib\liballoc-1085c790-0.11.0-pre.rlib(r-jemalloc-ctl.o):ctl.c:(.text+0x49d5): more undefined references to `__chkstk_ms' follow
collect2: ld returned 1 exit status

error: aborting due to previous error

Just to note I am running in Windows 7 any help would be much appreciated.

[alexcrichton]

The wiki is a bit outdated, I don't think we're compatible with gcc 4.5 any more. Can you provide a stack trace of the crash when using gcc 4.8?

[DarthShoge]

This has now been fixed. I think my initial installation of curl wasn't done quite correctly I ended up following the route described here to install curl http://www.multigesture.net/articles/how-to-upgrade-your-mingw-with-commonly-used-libraries/

[DarthShoge]

scratch that the run that i did that worked appears to have been an anomaly but hey at least its compiling again but unfortnately there is no kinda stack trace at all. The best i can get is the error details

Problem signature: Problem Event Name: APPCRASH Application Name: hello.exe Application Version: 0.0.0.0 Application Timestamp: 5381378c Fault Module Name: ntdll.dll Fault Module Version: 6.1.7601.18247 Fault Module Timestamp: 521ea8e7 Exception Code: c0000005 Exception Offset: 00038e19 OS Version: 6.1.7601.2.1.0.768.3 Locale ID: 2057 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

[alexcrichton]

Can you use gdb to get a backtrace? It sounds like your local mingw installation is corrupted, however, so you may want to try blowing it away and starting from scratch (we recommend you use mingw-w64 as well).

[klutzy]

This The build failure is mingw-3.x-specific issue since we migrated to mingw-w64.

From rt/rust_builtin.c:

struct tm* GMTIME(const time_t *clock, struct tm *result) {
    struct tm* t = gmtime(clock);
    if (t == NULL || result == NULL) { return NULL; }
    *result = *t;
    return result;
}

On mingw-w64, the definition of gmtime is:

#if !defined(_USE_32BIT_TIME_T)
__CRT_INLINE struct tm *__cdecl gmtime(const time_t *_Time) { return _gmtime64(_Time); }
#else
__CRT_INLINE struct tm *__cdecl gmtime(const time_t *_Time) { return _gmtime32(_Time); }
#endif

and _USE_32BIT_TIME_T is defined on mingw-w64. So our rustc.exe expects that you have _gmtime_32.

However old mingw 3.20 (gcc 4.6.2) does not have _gmtime32:

$ nm /mingw/lib/libmsvcrt.a  | grep gmtime
00000000 I __imp__gmtime
00000000 T _gmtime
00000000 T __gmtime64
00000000 I __imp___gmtime64

therefore it causes linker issues.

(Actually I think the rust_gmtime wrapper should be removed)

[DarthShoge]

Cheers guys I'm gonna do my utmost and post back with results

[DarthShoge]

Running gdb didn't get me any answers, it debugs just fine and exits with no error codes (see below) so the code itself is in good order but alas the executable is still crashing. p.s. i have even uninstalled and re-installed this time a fresh mingw-w64. so thinking it might be my environment is a mess I whipped out my laptop went through the motions....... and the same problem on there :S (ps these are both 64 bit systems) so not sure really. Can someone else try a reinstall and see if they can reproduce it on there box? I might try my brothers 32 bit system to see if it works there.

[klutzy]

Could you run which libgcc_s_dw2-1.dll? The result must be the path of your mingw installation (e.g. /mingw/bin/libgcc_s_dw2-1.dll).

[DarthShoge]

which libgcc_s_dw2-1.dll is returning me a slightly wrong result from my c: root I would expect it to return /mingw/mingw32/bin/libgcc.... but i am getting /mingw/bin/libgccc.... now what is strange here is my path in the environment variables is correct

but when i lookup $PATH it doesn't seem to have the right mingw path associated

This may all have nothing to do with the problem but i hope it helps

[DarthShoge]

I am finally getting some joy with the debugger It would appear that ntdll is being invoked via calling RtlIntegerToUnicodeString() which in turn is causing a segmentation fault

[klutzy]

@DarthShoge It seems that your gdb is from mingw-w64 ("i686-w64-mingw32"), not mingw ("i686-pc-mingw32"). It can be an evidence that you're experiencing dll incompatibility between mingw-w64 and mingw. Also I failed to reproduce the error on mingw 4.0 (gcc 4.8). That is, I succeeded to build and run hello-world example.

In any case, could you provide gdb backtrace? (backtrace command will work, and building hello with rust --debuginfo=2 may be better) Also, could you check PATH variable by echo $PATH?

[DarthShoge]

No unfortunately I do not use ConEmu at all so this might be a more general problem I can see that there is looks like there may be some incompatability issues but so far uninstalling and manual removal from the registry and re-installing has not helped i appear to consistantly be installing it incorrectly!

[pnkfelix]

it doesn't seem like there is anything here that the team can act upon.

Closing.

If someone provides a clear recipe for reproducing a state where one can reproduce this bug atop supported msys/mingw versions, then we can reopen (though then a fresh ticket may be best).