Building Julia on Windows fails due to libuv

[axsk]

Compiling Julia as described in the readme with MinGW/MSYS2 I get the following error after make clean and make (extract):

...
CC src/unix/libuv_la-async.lo
In file included from src/unix/async.c:26:0:
src/unix/internal.h:163:36: warning: 'struct msghdr' declared inside parameter list [enabled by default]
ssize_t uv__recvmsg(int fd, struct msghdr msg, int flags);
^
src/unix/internal.h:163:36: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
src/unix/internal.h:166:18: error: unknown type name 'uv__io_t'
void uv__io_init(uv__io_t w, uv__io_cb cb, int fd);
....
Makefile:1705: recipe for target 'src/unix/libuv_la-async.lo' failed
make[4]: *** [src/unix/libuv_la-async.lo] Error 1
Makefile:830: recipe for target 'all' failed
make[3]: *** [all] Error 2
Makefile:546: recipe for target 'libuv/.libs/libuv.a' failed
make[2]: *** [libuv/.libs/libuv.a] Error 2
...

For the full log see the gist.
What shall I do?

[tkelman]

libuv thinks you're on unix because you used the wrong batch file to start MSYS2. Use the mingw32_shell.bat, not msys2_shell.bat. We should probably document this better fix the docs. joyent/libuv#1199

[tkelman]

Or maybe it's not that issue, it's the "wrong gcc" issue #6234 (comment). What is the output of gcc -dumpmachine ?

[axsk]

i tried the mingw32_shell.bat, the mingw64_shell.bat and msys2_shell.bat, but none works.
gcc-dumpmachine returns x86_64-w64-mingw32 from each .bat

[ihnorton]

Do you have cygwin in your path?
On Sep 26, 2014 6:23 PM, "Alex" [email protected] wrote:

i tried the 'mingw32_shell.bat', the 'mingw64_shell.bat' and
'msys2_shell.bat', but none works.
'gcc-dumpmachine' returns 'x86_64-w64-mingw32' from each '.bat'

—
Reply to this email directly or view it on GitHub
#8488 (comment).

[tkelman]

How about uname -a ? Uploading deps/libuv/config.log to a gist would help too.

[axsk]

Depending on the .bat
MINGW32_NT-6.3 notebook 2.0.0(0.275/5/3) 2014-09-21 14:16 x86_64 Msys
MINGW64_NT-6.3 notebook 2.0.0(0.275/5/3) 2014-09-21 14:16 x86_64 Msys
MSYS_NT-6.3 notebook 2.0.0(0.275/5/3) 2014-09-21 14:16 x86_64 Msys

shoudln't i use the mingw64 if anything else is 64 bit?
here the 'deps/libuv/config.log'

[tkelman]

shoudln't i use the mingw64 if anything else is 64 bit?

Autotools doesn't recognize MINGW64 since it's slow to change and MSYS2 has only existed for a little over a year, so probably not. config.log looks like you were building in Cygwin (so @ihnorton called it), which won't work unless you provide XC_HOST = x86_64-w64-mingw32 (aka cross compile Cygwin-to-MinGW).

[tkelman]

PATH: /cygdrive/c/Program Files/Haskell Platform/2014.2.0.0/lib/extralibs/bin
PATH: /cygdrive/c/Program Files/Haskell Platform/2014.2.0.0/bin

God damn it Haskell Platform (cf. #7835 (comment)). @cartazio I know you're not a Windows guy, but who do we complain at to stop putting things on the path that break other projects in confusing ways?

[axsk]

i purged my path, moved cygwin and tried another make clean && make. same result
does make clean keep any configs / is there something stronger?

[tkelman]

make clean doesn't clean the dependencies. You want make distcleanall to start from scratch.

[axsk]

make distcleanall did help, at least im past the problematic file :)

edit: no more cygwin occurence in the libuv config.log
i probably tried make from julia sometime which messed up the config.
still compiling..

[tkelman]

It'll take a while, mostly due to LLVM and OpenBLAS. Get a coffee :) Hope you did make -j4 or more.

Moral of story: too much stuff permanently added to PATH = bad.

[axsk]

Finished compiling and works :)
Thanks a lot @tkelman
I don't think it was a path problem. Rather the make I surely tried sometime before from cygwin.

But I'm confused about when I want to use make clean and make distcleanall ..
Furthermore, when I start Julia the versioninfo states: x86_64-w64-mingw32. What does the firsts _64, the w64 and the 32 in the end stand for now?

[tkelman]

So make distcleanall will delete all of the built copies of OpenBLAS, LLVM, and all the other dependency libraries. make clean will just delete the built copies of core Julia. So from now on when you do git pull to update your source code, you probably want to do make clean && make so it won't take too long to rebuild, since we only change versions of the dependencies once a month or so.

x64_64-w64-mingw32 is what's called a "GNU triple." x86_64 means 64-bit x86, aka AMD64 or Intel64. This is most modern 64 bit PC processors. w64 is the "vendor," and stands for the MinGW-w64 project. This is a fork of mingw.org, "Minimalist GNU for Windows," which originally provided GCC compilers that target the Win32 API and MSVCRT runtime library. mingw.org only ever provided 32-bit compilers, and tends to lag behind official GCC sources in terms of modern compiler versions and language features, there are many patches required to create mingw.org compilers. MinGW-w64 was forked from mingw.org in order to provide 64-bit versions of GCC for Windows, but also took an alternate strategy of making sure all their patches were incorporated in the upstream GCC sources. So there are several different configurations and builds of MinGW-w64 that you can choose from, with one particular configuration favored for building Julia as spelled out in README.windows.md. Confusingly, the MinGW-w64 project provides both 64-bit and 32-bit versions of GCC for Windows. The GNU triple is i686-w64-mingw32 for 32 bit MinGW-w64, vs i686-pc-mingw32 for 32 bit mingw.org. The mingw32 at the end is common between the two projects because both target the "Win32" system API. Very confusing, I know. To add to the confusion, LLVM recently added its own set of slightly different names on top of this.

[cartazio]

@tkelman heya! I'm totally not involved in the haskell-platform stuff (if thats still related at alll) , but https://github.com/haskell/haskell-platform is where to got if you've got bugs to report. (I also think i'm WAYY overdue on replying to an email of yours, been a bit buried with life matters the past month or two)

[tkelman]

Nevermind, I think Haskell Platform escapes the blame here for the moment, but next time I see it on someone's path I'm submitting a bug.

[axsk]

thanks a lot @tkelman for the detailed explanation 👍