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
