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