I've created a patch which allows to build Rust on latest mingw without manual patching: https://github.com/vadimcn/rust/commit/49bbb0a219883f2af6b71c58faad7c009aed159a With this, Rust builds and passes all tests, except for the ones caused by GCC ABI change <https://github.com/mozilla/rust/issues/9205>.
Brian, would it be acceptable to commit this in order to unblock migration to latest mingw? Vadim On Mon, Sep 16, 2013 at 7:25 AM, Thad Guidry <thadgui...@gmail.com> wrote: > Good Job on documenting the build steps, Dandy ! Closer and closer we get > to flawless building on Windows. > > > On Mon, Sep 16, 2013 at 1:51 AM, Aaron Dandy <aaron.da...@live.com> wrote: > >> Klutzy helped me through a bunch of issues tonight and I am now building >> stage 2 from HEAD using GCC 4.8. I put the procedure I used up on the >> GitHub wiki for others to try and also linked it from the main getting >> started page: " >> https://github.com/mozilla/rust/wiki/Note-Building-Rust-Before-0.8-on-Windows-Systems >> . >> Huge thanks for Klutzy helping me out. >> >> Aaron@GIR /c/projects/rust/i686-pc-mingw32/stage2/bin >> $ rustc.exe hello.rs >> >> Aaron@GIR /c/projects/rust/i686-pc-mingw32/stage2/bin >> $ hello >> Hello, world. >> >> > Date: Sun, 15 Sep 2013 14:33:41 +0900 >> > From: klutzytheklu...@gmail.com >> > To: vadi...@gmail.com >> > CC: rust-dev@mozilla.org >> > Subject: Re: [rust-dev] Windows Users can build Rust properly again ! >> >> > >> > The error is due to abi change of win32 gcc. reported here: >> > https://github.com/mozilla/rust/issues/9205 >> > >> > On Sat, Sep 14, 2013 at 4:52 PM, klutzy <klutzytheklu...@gmail.com> >> wrote: >> > > I've finished `make` on gcc 4.8.1, but `make check-fast` failed: >> > > >> > > task <unnamed> failed at 'assertion failed: `(left == right) && >> > > (right == left)` >> > > (left: `t_317::TwoU64s{one: 98784247808u64, two: 257698037760u64}`, >> > > right: `t_317::TwoU64s{one: 22u64, two: 94489280535u64}`)', >> > > >> C:\home\stone\rust-vanilla\src\test\run-pass\extern-pass-TwoU64s-ref.rs:27 >> > > make: *** >> [i686-pc-mingw32/test/run_pass_stage2_driver-i686-pc-mingw32.out] >> > > Error 101 >> > > >> > > I previously met this when I tested on mingw-w64/32bit. >> > > (https://github.com/mozilla/rust/issues/8996) >> > > Seems like the failure is related to recent gcc. >> > > >> > > >> > > On Sat, Sep 14, 2013 at 3:35 PM, klutzy <klutzytheklu...@gmail.com> >> wrote: >> > >> some more explanation: >> > >> >> > >> #include <fenv.h> causes /lib/gcc/mingw32/<ver>/include/c++/fenv.h to >> > >> be included. >> > >> The header contains: >> > >> >> > >> #include <bits/c++config.h> >> > >> #if _GLIBCXX_HAVE_FENV_H >> > >> # include_next <fenv.h> >> > >> #endif >> > >> >> > >> where bits/c++config.h is at >> /lib/gcc/mingw32/<ver>/include/c++/mingw32. >> > >> However, for some reason (I don't know), they removed `#define >> > >> _GLIBCXX_HAVE_FENV_H 1` somewhere between 4.6.2 and 4.8.1. >> > >> so `#include_next <fenv.h>` does not occur, which is >> > >> `/include/fenv.h`. It contains some definitions e.g. `FE_ALL_EXCEPT`. >> > >> >> > >> On Sat, Sep 14, 2013 at 3:25 PM, klutzy <klutzytheklu...@gmail.com> >> wrote: >> > >>> I've solved it some minutes ago :) >> > >>> >> > >>> <klutzy> at >> /path/to/mingw/lib/gcc/mingw32/<ver>/include/c++/mingw32/bits/c++config.h: >> > >>> <klutzy> there is #define _GLIBCXX_HAVE_FENV_H 1 in 4.6.1's header >> > >>> <klutzy> but there isn't [such #define] in 4.8.1 header. >> > >>> <klutzy> this causes /include/fenv.h not included when llvm does >> > >>> #include <fenv.h> >> > >>> >> > >>> The c++config.h has such lines: >> > >>> /* Define to 1 if you have the <fenv.h> header file. */ >> > >>> /* #undef _GLIBCXX_HAVE_FENV_H */ >> > >>> >> > >>> I added `#define _GLIBCXX_HAVE_FENV_H 1` at the file directly, and >> it >> > >>> works. We can't recommend users to do this hack though. >> > >>> >> > >>> >> > >>> >> > >>> On Sat, Sep 14, 2013 at 3:21 PM, Vadim <vadi...@gmail.com> wrote: >> > >>>> Yes, but we can't check this into Rust repo. Maybe it can be >> worked around >> > >>>> by -DWSAPOLLFD somewhere in makefiles... >> > >>>> >> > >>>> And just as a heads-up, these seems to be another problem,- with >> LLVM: >> > >>>> http://sourceforge.net/p/mingw/bugs/2043/ >> > >>>> >> > >>>> Vadim >> > >>>> >> > >>>> On Sep 13, 2013, at 9:16 PM, klutzy k <klutzytheklu...@gmail.com> >> wrote: >> > >>>> >> > >>>> Mingw added new winapi at mswsock.h: >> > >>>> >> > >>>> #if (_WIN32_WINNT >= _WIN32_WINNT_VISTA) >> > >>>> int WSAAPI WSAPoll(WSAPOLLFD, ULONG, INT); >> > >>>> >> > >>>> #endif >> > >>>> >> > >>>> but they forgot to add definition of WSAPOLLFD. >> > >>>> >> > >>>> Someone submitted patch at >> http://sourceforge.net/p/mingw/bugs/1980/ >> > >>>> but seems like it's not on mainstream. >> > >>>> >> > >>>> Anyway, we (including libuv) don't use the api. Removing the >> codeblock helps >> > >>>> us. >> > >>>> >> > >>>> On Fri, Sep 13, 2013 at 3:19 PM, Vadim <vadi...@gmail.com> wrote: >> > >>>> >> > >>>> Hmm. Looks like mingw released a new version with gcc 4.8 and that >> somehow >> > >>>> >> > >>>> broke mswsock.h (though the file didn't change). >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> On Thu, Sep 12, 2013 at 6:56 PM, Thad Guidry <thadgui...@gmail.com> >> wrote: >> > >>>> >> > >>>> >> > >>>> Doesn't work... >> > >>>> >> > >>>> >> > >>>> Errors regarding libuv and mswsock... >> > >>>> >> > >>>> >> > >>>> http://pastebin.mozilla.org/3038909 >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> On Thu, Sep 12, 2013 at 5:06 PM, Vadim <vadi...@gmail.com> wrote: >> > >>>> >> > >>>> >> > >>>> Hi Brian, >> > >>>> >> > >>>> >> > >>>> Actually, I would argue that these changes *should* be made before >> 0.8 >> > >>>> >> > >>>> release in order to smoothen the path of people who will install >> 0.8 to try >> > >>>> >> > >>>> it out. >> > >>>> >> > >>>> >> > >>>> Regarding the work to be done, as far as I know all you need is: >> > >>>> >> > >>>> 1. Save libgcc_s_dw2-1.dll and libstdc++-6.dll from %mingw%\bin >> > >>>> >> > >>>> 2. "mingw-get update" >> > >>>> >> > >>>> 3. "mingw-get upgrade" >> > >>>> >> > >>>> 4. run %rust%\configure (not sure if actually needed, but won't >> hurt) >> > >>>> >> > >>>> 5. "make clean" >> > >>>> >> > >>>> 6. "make check", which will fail at building stage1 std crate >> because >> > >>>> >> > >>>> step 3 upgraded libgcc and libstdc++ and stage0 compiler needs >> them. >> > >>>> >> > >>>> 7. copy dlls saved in step 1 into >> %rust%\build\i686-pc-mingw32\stage0\bin >> > >>>> >> > >>>> 8. "make check" again, which should succeed this time >> > >>>> >> > >>>> >> > >>>> Can somebody please verify that this works? >> > >>>> >> > >>>> >> > >>>> >> > >>>> Re mingw-w64: sort of works, however its' phtreads implementation >> seems >> > >>>> >> > >>>> to be buggy. Also see this thread. I don't think we'll should >> migrate to >> > >>>> >> > >>>> it just yet. >> > >>>> >> > >>>> >> > >>>> Vadim >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> On Thu, Sep 12, 2013 at 2:10 PM, Brian Anderson < >> bander...@mozilla.com> >> > >>>> >> > >>>> wrote: >> > >>>> >> > >>>> >> > >>>> On 09/12/2013 12:39 PM, Thad Guidry wrote: >> > >>>> >> > >>>> >> > >>>> Yeah, there should not be a reason anymore, if I am correct, to >> not have >> > >>>> >> > >>>> GCC 4.7 in MinGW for Rust Windows users anymore. I will give that >> a try >> > >>>> >> > >>>> also , and if it works, then we can close out (#8598). (I also >> would like >> > >>>> >> > >>>> to get rid of the 4.5 downgrade needed).... but that does need >> more testing >> > >>>> >> > >>>> from the core Rust team and others. >> > >>>> >> > >>>> >> > >>>> It's something that Brian has been counting on me to help make >> happen, >> > >>>> >> > >>>> and Alex is also contributing to some of that effort by fixing >> various LLVM >> > >>>> >> > >>>> build issues that affect Windows Rust users as you mention in >> (#8598). >> > >>>> >> > >>>> >> > >>>> Agreed, if a new stage0 compiler snapshot can be created, then we >> should >> > >>>> >> > >>>> be in the clear to also close out #5878. >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> Thanks for everybody's amazing contributions to our Windows >> support. If >> > >>>> >> > >>>> somebody makes the changes necessary to work with a newer >> toolchain then we >> > >>>> >> > >>>> will upgrade the bots. It's unlikely we can do this before 0.8 >> though, due >> > >>>> >> > >>>> in two weeks. >> > >>>> >> > >>>> >> > >>>> I gather that some folks would like to switch to the mingw-w64 >> toolchain >> > >>>> >> > >>>> as well. Is that in the cards here? >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> >> > >>>> Rust-dev mailing list >> > >>>> >> > >>>> Rust-dev@mozilla.org >> > >>>> >> > >>>> https://mail.mozilla.org/listinfo/rust-dev >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> >> > >>>> Rust-dev mailing list >> > >>>> >> > >>>> Rust-dev@mozilla.org >> > >>>> >> > >>>> https://mail.mozilla.org/listinfo/rust-dev >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> -- >> > >>>> >> > >>>> -Thad >> > >>>> >> > >>>> Thad on Freebase.com >> > >>>> >> > >>>> Thad on LinkedIn >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> >> > >>>> Rust-dev mailing list >> > >>>> >> > >>>> Rust-dev@mozilla.org >> > >>>> >> > >>>> https://mail.mozilla.org/listinfo/rust-dev >> > >>>> >> > >>>> >> > _______________________________________________ >> > Rust-dev mailing list >> > Rust-dev@mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> > > > -- > -Thad > Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry> > Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/> > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
