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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>
>> Doesn't work...
>>
>>
>> Errors regarding libuv and mswsock...
>>
>>
>> http://pastebin.mozilla.org/3038909
>>
>>
>>
>>
>> On Thu, Sep 12, 2013 at 5:06 PM, Vadim <[email protected]> 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 <[email protected]>
>>
>> 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
>>
>> [email protected]
>>
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
>>
>> _______________________________________________
>>
>> Rust-dev mailing list
>>
>> [email protected]
>>
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>
>>
>>
>> --
>>
>> -Thad
>>
>> Thad on Freebase.com
>>
>> Thad on LinkedIn
>>
>>
>>
>>
>> _______________________________________________
>>
>> Rust-dev mailing list
>>
>> [email protected]
>>
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
