Re: [rust-dev] Windows Users can build Rust properly again !
So, in my experiments tonight... I had to have the following copied into stage0/bin in order to build with mingw32 (gcc 4.8.1) Older libstdc++-6.dll which I got from here: http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.6.2-1/libstdc%2B%2B-4.6.2-1-mingw32-dll-6.tar.lzma/download AND libpthread-2.dll (which I created by copying renaming pthreadGC2.dll ) ... and now it builds just fine with i686-pc-mingw-32. I also agree with klutzy that we should bundle them for now. (and will enjoy getting a Clang build version to work from stage0 + whenever we can muster that origami) On Fri, Sep 20, 2013 at 12:49 AM, klutzy klutzytheklu...@gmail.com wrote: I wonder if we should just bundle runtime libraries with the stage0 snapshot in the future? I think we should bundle them: https://github.com/mozilla/rust/issues/9252 On Thu, Sep 19, 2013 at 7:16 AM, Vadim vadi...@gmail.com wrote: Okay, looks like my mingw 4 fix went in last night. Here's my personal recipe for setting up mingw: 1. Download and install mingw-get 2. Install the required packages. One can do this in GUI, but I prefer the command line, as it's less ambiguous: mingw-get install mingw-developer-toolkit mingw-get install mingw32-base mingw-get install mingw32-gcc-g++ mingw-get install mingw32-libpthreadgc mingw-get install msys-wget 3. Install GIT and Python, make sure they are on the PATH 4. In MSYS shell: ../configure; make check-fast Until stage0 snapshot compiler has been rebuilt with new mingw, stage0 compilation will fail because latest mingw has wrong versions of the runtime libraries that rustc depends on. So: 5.. Get old versions of these dlls: mingw-get upgrade g++4.6 mingw-get upgrade libpthread=2.8.0-3 6.. Copy libgcc_s_dw2-1.dll, libstdc++-6.dll and libpthread-2.dll from %mingw%\bin into %build%\i686-pc-mingw32\stage0\bin. 7. Roll mingw back to the latest: mingw-get upgrade 8.. make check-fast I wonder if we should just bundle runtime libraries with the stage0 snapshot in the future? Vadim On Mon, Sep 16, 2013 at 6:33 PM, Alex Crichton acrich...@mozilla.com wrote: Hey guys, so we're gonna hold off on upgrading the windows builders until we're 100% sure that we won't bork them with a mingw upgrade. What I think that we can do, on the other hand, is: 1. Land Vadim's patch onto master 2. I spin up a clean windows vm (need to do that anyway) 3. Could you guys send me a list of instructions to build rust on the most recent mingw? 4. Once verified, and possible bugs fixed, we can go upgrade the builders and documentation about mingw Ideally the build instructions would be: A. Acquire mingw. B. Acquire relevant gcc version 4.X C. ./configure make It'd be awesome to keep it that simple, and it seems that your patches would have eliminated the need for patching system files? How does that sound to you guys? On Sep 16, 2013, at 6:20 PM, Vadim vadi...@gmail.com wrote: -- -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
Re: [rust-dev] Windows Users can build Rust properly again !
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$ helloHello, 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
Re: [rust-dev] Windows Users can build Rust properly again !
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
Re: [rust-dev] Windows Users can build Rust properly again !
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
Re: [rust-dev] Windows Users can build Rust properly again !
On 09/16/2013 05:39 PM, Vadim wrote: 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 changehttps://github.com/mozilla/rust/issues/9205. Brian, would it be acceptable to commit this in order to unblock migration to latest mingw? Yes, but please add some comments explaining what's going on. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
Ok. How do you want to go about upgrading build bots once this is in? BTW, looks like it is no longer possible to downgrade mingw to gcc 4.5. mingw-get upgrade g++4.6 says mingw-get: *** ERROR *** there is no release matching g++4.6... I think we should save a copy of existing mingw folder in case unexpected problems are discovered. Vadim On Mon, Sep 16, 2013 at 5:58 PM, Brian Anderson bander...@mozilla.comwrote: On 09/16/2013 05:39 PM, Vadim wrote: 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? Yes, but please add some comments explaining what's going on. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Windows Users can build Rust properly again !
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
Re: [rust-dev] Windows Users can build Rust properly again !
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
Re: [rust-dev] Windows Users can build Rust properly again !
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
Re: [rust-dev] Windows Users can build Rust properly again !
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 https://github.com/mozilla/rust/issues/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 https://github.com/mozilla/rust/issues/8598). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878 https://github.com/mozilla/rust/issues/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
Re: [rust-dev] Windows Users can build Rust properly again !
Yes, that's the game plan I have...and klutzy and Vadim getting the mingw-w64 toolchain working. On Thu, Sep 12, 2013 at 4:10 PM, Brian Anderson bander...@mozilla.comwrote: 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 (#8598https://github.com/mozilla/rust/issues/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 (#8598https://github.com/mozilla/rust/issues/8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878https://github.com/mozilla/rust/issues/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 -- -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
Re: [rust-dev] Windows Users can build Rust properly again !
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 https://github.com/mozilla/rust/issues/8996#issuecomment-24292739. Also see this threadhttp://sourceforge.net/mailarchive/forum.php?thread_name=CAKEnbTNV4iDok-k9Gg-Wmr85utFPxLf4wmAabjJZ1WaCFVE5PQ%40mail.gmail.comforum_name=mingw-w64-public. 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.comwrote: 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 (#8598https://github.com/mozilla/rust/issues/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 (#8598https://github.com/mozilla/rust/issues/8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878https://github.com/mozilla/rust/issues/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
Re: [rust-dev] Windows Users can build Rust properly again !
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 buggyhttps://github.com/mozilla/rust/issues/8996#issuecomment-24292739. Also see this threadhttp://sourceforge.net/mailarchive/forum.php?thread_name=CAKEnbTNV4iDok-k9Gg-Wmr85utFPxLf4wmAabjJZ1WaCFVE5PQ%40mail.gmail.comforum_name=mingw-w64-public. 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.comwrote: 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 (#8598https://github.com/mozilla/rust/issues/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 (#8598https://github.com/mozilla/rust/issues/8598 ). Agreed, if a new stage0 compiler snapshot can be created, then we should be in the clear to also close out #5878https://github.com/mozilla/rust/issues/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 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
