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

Reply via email to