README.windows could be clearer

[jiahao]

The windows build instructions could be cleaned up.

• try msys2 compile
• clearer step-by-step instructions about setting up Windows path and msys prompt

I set up a brand new Win7 VM and followed all the instructions in README.windows.md. However, following the instructions to the letter brings me to the point where I can get a useable msys prompt but with no compilers. It is not clear how to proceed, since the instructions explicitly discourage obtaining the necessary compilers from the usual place at mingw.org.

[ihnorton]

There are links under item 1 of the heading "Native Compile". (though you may be better off with msys2 builds)

[jiahao]

Oh wow I feel stupid now. I downloaded the .7z archive but didn't unpack it to C:\Mingw.

Thanks for reminding me about msys2. I'll try it and fix up the README in short order.

[ihnorton]

@karbarcca what are you using to compile?

[jiahao]

Reminder to self: Useful instructions in the discussion in #3640

[quinnj]

Just saw I was pinged here. Sorry for the no response. I've been using msys2 as well as the mingw64 packaged by the same team. There's a single pcre issue with a few tests that fail, but other than that, the build has been pretty stable for a few months now.

[vtjnash]

@jiahao Do you think you could update them? You probably have the most familiarity with the new-user difficulties of the instructions.

Also needing updating in there: usr/lib no longer exists, the %PATH% variable no longer matters, and julia.bat is no longer needed for launching julia

[jiahao]

@vtjnash will do. Would like to see #4589 fixed also.

[vtjnash]

yeah, me too...

Anyways, I didn't know you were hitting that also. Is that something I could likely reproduce? I have a XP-64 VM I can try building to see if I get the error.

[jiahao]

Probably. I reproduced the problem on a clean native 64bit 8.1 install with latest mingw and msys2.

[jiahao]

Update: the windoc branch is now completely updated to recommend the mingw-build + msys2 stack. Will close once #4589 is fixed.

[vtjnash]

@jiahao I can't make comments on the branch w/o a pull request, so I'll write them here: there's some formatting issues with the lists of commands. Do the fstab command have any effect? The readme mentions that julia.bat is the preferred way to start julia; however, that is no longer true.

[jiahao]

The julia.bat thing has its own issue, so I'm not considering it here. I can't proceed beyond this point without a working build. The formatting problem seems to be a result of Github not recognizing four-space indents.

The command involving the fstab edit mounts mingw-build. I tried msys2's built-in mingw toolchain but it is hard-coded to use posix threads, which I gathered from the existing documentation was a Bad Thing.

[ihnorton]

I don't know if it's a good idea to recommend msys2 as the default yet. As I mentioned, there seem to be persistent memory release issues. Using msys2 I've had (several) BSOD crashes, the only ones I've ever seen on Win7.

[jiahao]

I just updated msys2 today and saw the process fork failure issues you reported also, so now I'm less sure of recommending that too.

It's too bad, since msys2 is somewhat less work than msys.

[jiahao]

Btw, can someone explain to me why exactly

• posix threads are worse than win32 threads, and
• what happened with gcc46 (why is it bad?)
• what is the deal with sjlj vs seh vs dwarf2 (googling gets me descriptions of what sjlj and seh are, but not their relative merits or performance vs dwarf2)

[ihnorton]

posix, see #4360 and #3242 (comment)

gcc46 doesn't compile OpenBLAS correctly: https://groups.google.com/forum/#!searchin/julia-dev/"gcc$204.6"/julia-dev/Pj6ZWl7VFik/IuiIU_D2v7sJ

dwarf + llvm, codegen doesn't work: #4589 (comment)

sjlj is just slow, I think.

[vtjnash]

gcc46 also has several mistakes in the windows calling convention that make it somewhat incompatible with native windows code

Hmm, I wonder if sjlj would fix backtraces on windows. The trick would be ensuring we never use a dll that has seh marking, to avoid triggering certain heuristics in the windows kernel which is causing it to ignore our error handlers.

dwarf2 presupposes that you don't mix JIT code and C++ code. it doesn't end up being much of a problem for julia, but it's an unnecessary risk.

persistent memory release issues.

these exist in msys also. apparently it is an upstream bug in make (which has been fixed in cygwin?)

msys2's built-in mingw toolchain

When I last checked (a few weeks ago?), msys2-base built-in toolchain was a msys2 compiler. That would be very different from a mingw toolchain and is definitely not something you want to use for julia.

[jiahao]

@vtjnash is the msys2 compiler the thing that lives in msys2's mingw package repo?

[ihnorton]

these exist in msys also. apparently it is an upstream bug in make (which has been fixed in cygwin?)

I am on a very recent release of make, 4.0.90. It seems like every time it spawns a new sub-process, the memory usage goes up by 2MB (watching the compile alongside svchost memory usage). The memory usage does not go down.

@vtjnash do you have a link to the make bug report? there is a lot of noise.

[ihnorton]

also, gdb appears to be broken :(
history doesn't work, and trying to set breakpoint I get: Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]. seems like gdb/readline is not playing nice.

[vtjnash]

@jiahao I didn't realize there was another repo. I believe you get an msys compiler if you type pacman -S gcc

@ihnorton I've never looked for the bug report, I used to just reboot my computer 3 times (roughly every 12 hours) during a msys compile to keep it running with a minimum number of corrupted files by the end. loladiro used to do the same (before he left windows). In fact, this was part of my motivation for setting up the cross build -- so my release builds wouldn't have random corruption caused by windows OOM-induced crashes (and make parallelization bugs, which have been fixed in msys2).

@ihnorton gdb refused to launch for me -- I used the gdb from mingw-w64 instead. I think Alexpux would appreciate this as a bug report on his msys2 sourceforge page.

[ihnorton]

Well here is one extensive thread: http://cygwin.com/ml/cygwin/2011-07/msg00264.html