Use Mingw-w64 for Win32 #8996
Comments
|
Some more thoughts: mingw-w64 has no 'official' binary: I think mingw-builds is most widely used, but I guess rubenvb's personal build is also quite popular. For mingw-builds, there are many options available: platform (win32/win64), thread model (posix/win32 for both platform) and stack unwinding model (sjlj/dwarf for 32-bit, sjlj/seh for 64-bit). I've only used win32 (threads) and dwarf/win32 & seh/win64 (unwinding) so far. We have to choose some model among them for 'official' rust binary because performance and compatibility matter. On stack unwinding models:
Actually I've already built win32 rust on mingw-w64 (platform 32-bit, threads win32, exception dwarf), but |
|
There are /testing versions in the mingw-builds sourceforge repository as well. Also, there are build scripts to build a mingw-build, version yourself, which is found here: http://sourceforge.net/p/mingwbuilds/code/ci/master/tree/ @klutzy I also have been able to build win32 rust, and noticed the same issues as you on my Win7 64 bit Intel PC |
|
@klutzy rubenvb's builds are coordinated with a few of the Mingw developers/contributors...namely jon_y. But the his builds might not incorporate the very latest releases available of gcc. The mingw-build guys seem to keep a bit more up to date. Of note is the inclusion of Clang with rubenvb's builds.... that alone might sway a vote of confidence. It is probably best to ask someone like jon_y or others on the official Mingw mailing list itself. |
|
@klutzy We also ideally need a way to pass down the -L option during ./configure , since I try different toolchains, all usually within the same basic PATH of c:\mingw-toolchains. What ends up happening is that the ld.exe during the LLVM configure steps gets the wrong library path through the LDFLAGS and ends up throwing an error: C compiler cannot create executables See 'config.log' for more details... configure:2124: $? = 0 |
|
Yes, rustc built with mingw-w64 (from mingw-builds) is very slow. Profiling points towards libwinpthreads' implementation of mutexes. I've checked out the source, and apparently they are implemented using Windows semaphores, which would explain why they are so slow: win32 semaphores are kernel objects, so every lock/unlock entails a syscall. On the other hand, pthreads-win32 library, used by the regular mingw, looks much more reasonable - it first tries to obtain a lock via interlocked exchange, and only then falls back onto syscalls. Here's the bug I've opened in mingw-w64 issue tracker: https://sourceforge.net/p/mingw-w64/bugs/344/ |
|
For record, I built rust on mingw-w64/32-bit where gcc version is 4.8.1. The failure was at |
|
@klutzy In that case, we could REALLY use your notes on a new Wiki Page (or GIST) so that all of us can compare how your actually doing this and your step by steps. Can you do this please ? |
|
@thadguidry On mingw-64's 32-bit toolchain, I did it really straightforwardly: 1) set msys to use mingw-w64's toolchain. 2) copy some mingw dlls (e.g. libgcc_s_dw2-1.dll) to |
|
I cannot get gcc to be found in the PATH at all, with a clean installation of MinGW with the new steps..https://github.com/mozilla/rust/wiki/Note-getting-started-developing-Rust I need help from you in how you were able to get gcc found correctly on Win7 using those steps. When I do "which gcc", it cannot be found. Can you enlighten me ? How are you launching Msys on Win7 ? Did you change your path and where ? Did you change your /etc/profile in Msys , and how so ? That's what I need help understanding. Start with a clean slate, and try the steps on getting started, and let me know where things are incorrect and how they differed for you... |
|
Oh my. mingw installer does not set msys configuration at all. I didn't recognized it since I always did it manually. This script asks mingw directory ( It is same for mingw-w64 except that you should download msys manually. |
|
tests expected to fail:
|
|
Klutzy, Your a hero ! That did the trick. And it looks like it was just a simple I will update our Getting Started wiki. Thanks ! On Sat, Sep 14, 2013 at 11:31 PM, klutzy [email protected] wrote:
-Thad |
|
Yet another issue this would fix: #10315 |
|
accepted for P-high, want this for 1.0. |
|
(NOTE: here If you run In the other hand, mingw-w64 provides a lot of options: exception model (dwarf / sjlj) and threading model (win32 / posix). I'm curious if this affects some compatibility. |
|
I found |
|
@klutzy As I mentioned here, the reason for slowness seems to be sub-optimal implementation of mutexes in libwinpthreads that is bundled with mingw-w64. I could be wrong, of course, so perhaps this should be looked over by a second pair of eyes. I've used the VerySleepy profiler. |
|
Steps to get "bootstrapped" rustc: (outdated: see below)
Again, I used mingw-builds |
This patchset fixes some parts broken on Win64. This also adds `--disable-pthreads` flags to llvm on mingw-w64 archs (both 32-bit and 64-bit, not mingw) due to bad performance. See #8996 for discussion.
|
Now |
|
The bots are switched over to mingw-w64 and I've attempted to update the docs on the wiki to reflect. |
We currently use mingw for win32 platform. However mingw does not support win64 (#1237), so we have to use mingw-w64 (or msvc: #1768).
Although mingw and mingw-w64 looks similar, implementations differ: we have issues due to mingw which are already solved on mingw-w64. (#8663, #8859)
Instead, we may switch to mingw-w64 for win32. (Yes, mingw-w64 supports win32 despite its name.) then we can reduce platform/runtime differences between win32/win64.
Previously @thadguidry posted about Qt's discussion on mingw/mingw-w64. (original discussion)
also cc @vadimcn :)
The text was updated successfully, but these errors were encountered: