Native Windows 8 Build

[quinnj]

I think there's growing interest in improving the native windows build process (from comments about wanting 0.2 binaries, etc.). I know I'd personally love to get it working as well. I also know that @vharavy has been doing related work here, so if there's major changes coming along that make improving the mingw/msys build not worth it, just let me know.

Following the windows.readme this morning, my build doesn't get very far before snagging an error on linking random. Inspecting usr/lib, I thought it was interesting that libgrisu.so and librandom.so are .so files instead of .dll files. Is the shared library extension not getting set right or is this right?

c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw3
2/bin/ld.exe: cannot find -lrandom
collect2.exe: error: ld returned 1 exit status
make[3]: *** [libRmath.] Error 1
make[2]: *** [Rmath/src/libRmath.so] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

Full build log: https://gist.github.com/karbarcca/5612472

Any help/direction is much appreciated!

[vtjnash]

Can you post the results of running uname -s, please.

[quinnj]

karbarcca@quinnj /c/Users/karbarcca/julia
$ uname -s
MINGW32_NT-6.2

I'm on windows 8, 64-bit.

[vtjnash]

As I suspected, the makefile only works on Windows 7. Which is silly, because it was lazy. The detection logic in Make.inc needs to be fixed

@karbarcca In Make.user you can add the following to force it to work:

override OS=WINNT
override BUILD_OS=WINNT

[quinnj]

Ok, I added the lines to Make.user. It now catches on

i387/s_ceil.S: Assembler messages:
i387/s_ceil.S:10: Error: invalid instruction suffix for `push'
make[3]: *** [i387/s_ceil.S.o] Error 1
make[2]: *** [openlibm/libopenlibm.dll] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

I've updated the build log above to the new full output.

[quinnj]

Seems like the above error is a 32/64-bit compatibility issue (from googling). In the openlibm make file, it uses uname -m to get the ARCH, which returns i686 on my mingw. Adding override ARCH=x86_64 to the Make.user seems to get past this.

[quinnj]

It now snags while building LLVM:

c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw3
2/bin/ld.exe: c:/Users/karbarcca/julia/deps/llvm-3.2/build/Release/lib/libLLVMJI
T.a(JIT.o): bad reloc address 0x0 in section `.pdata$_ZN4llvm16JITEventListener2
1NotifyFunctionEmittedERKNS_8FunctionEPvyRKNS_31JITEvent_EmittedFunctionDetailsE
'
collect2.exe: error: ld returned 1 exit status
make[5]: *** [/c/Users/karbarcca/julia/deps/llvm-3.2/build/Release/bin/lli.exe]
Error 1
make[4]: *** [lli/.makeall] Error 2
make[3]: *** [all] Error 1
make[2]: *** [llvm-3.2/build/Release/lib/libLLVMJIT.a] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

I've updated the original build log with as much output as I could get.

[vharavy]

Have you done modifications of LLVM mentioned in Build Errata?

[quinnj]

To make sure I'm doing it right

#define HAVE_EHTABLE_SUPPORT 1
#else
#define HAVE_EHTABLE_SUPPORT 0

becomes

#define HAVE_EHTABLE_SUPPORT 0
#else
#define HAVE_EHTABLE_SUPPORT 0

[vharavy]

Seems right. Make sure to run make clean (or even better make cleanall) after these modifications.

[vtjnash]

You don't need to run make clean after this modification. That change is fine, or you can collapse it into one statement and remove the #if block also

[quinnj]

Running make clean actually reverted my change, so the key is to not run it to keep the change. So everything seemed to build fine until I hit MPFR section where most of the tests failed.

=======================
144 of 160 tests failed
(1 test was not run)
=======================
make[5]: *** [check-TESTS] Error 1
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [mpfr-3.1.2/checked] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

I updated my original build log, but it's mostly failed tests.
I'll try to do some research on it, but any thoughts?

[vharavy]

I had the same problem on Windows 7 64-bit since Windows build started using MinGW 4.8. No idea how to resolve this.

[vtjnash]

It sounds like this is a different error that should have a separate bug report.

[andrioni]

Try using the MinGW MPFR. As MPFR is one of the GCC deps, you almost never should have to compile it manually, and I think it's possible to build BigFloat on MPFR 2.4.x if you comment out digamma.

[quinnj]

So after researching the mpfr bug, it sounds like there are 2 issues. The first is some kind of TLS support issue and is solved by adding the --disable-thread-safe flag. This solved most of my MPFR build problems. The other is a recurring thing when building on windows (there were threads back in 2009, 2010, and with the most recent 3.1.2 version) with a problem with the windows runtime and printf, which supposedly can be solved by adding the -D__USE_MINGW_ANSI_STDIO switch to your gcc configure, but I still can't seem to get the last 3 tests related to printf to pass (it's highly possible I'm missing something obvious). Anyway, the consensus is that it still runs fine even though those 3 tests don't pass, so I went ahead and built manually and switched USE_SYSTEM_MPFR=1 to get past it in the build script (though I'm not really sure how it's supposed to link afterwards to system, does it need to be in system path?).

[quinnj]

Everything then seems to compile fine until the final linking, I get this error (which seems identical to the earlier bug with LLVM JIT)

    FLISP src/julia_flisp.boot
    FLISP src/julia_flisp.boot.inc
    CC src/ast.o
    CC src/builtins.o
    CC src/module.o
    CC src/codegen.o
    CC src/interpreter.o
    CC src/alloc.o
    CC src/dlload.o
    CC src/sys.o
    CC src/init.o
    CC src/task.o
    CC src/array.o
    CC src/dump.o
    CC src/toplevel.o
    CC src/jl_uv.o
jl_uv.c: In function 'getlocalip':
jl_uv.c:664:12: warning: unused variable 'tmpAddrPtr' [-Wunused-variable]
     void * tmpAddrPtr=NULL;
            ^
    CC src/jlapi.o
    CC src/gc.o
    LINK usr/lib/libjulia-release.dll
c:/Users/karbarcca/julia/usr/lib/libLLVMJIT.a(JIT.o):JIT.cpp:(.text+0x452f): und
efined reference to `__register_frame'
c:/Users/karbarcca/julia/usr/lib/libLLVMJIT.a(JIT.o):JIT.cpp:(.text+0x4540): und
efined reference to `__deregister_frame'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw3
2/bin/ld.exe: c:/Users/karbarcca/julia/usr/lib/libLLVMJIT.a(JIT.o): bad reloc ad
dress 0x0 in section `.pdata$_ZN4llvm15ExecutionEngine14finalizeObjectEv'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [/c/Users/karbarcca/julia/usr/lib/libjulia-release.dll] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

[quinnj]

After running make clean and make cleanall, it gets a little further.

    LINK usr/lib/libjulia-release.dll
    PERL base/pcre_h.jl
    PERL base/errno_h.jl
    PERL base/build_h.jl
    PERL base/file_constants.jl
    PERL base/uv_constants.jl
    CC ui/repl.o
    CC ui/repl-basic.o
    LINK usr/bin/julia-release-basic.exe
    CC ui/repl-readline.o
    LINK usr/bin/julia-release-readline.exe
    JULIA usr/lib/julia/sys.ji
Please submit a bug report with steps to reproduce this fault, and any error mes
sages that follow (in their entirety). Thanks.

*** This error is usually fixed by running 'make clean'. If the error persists,
try 'make cleanall'. ***

[vharavy]

Yeah, this is a well-known issue. Unfortunately, this is no known solution to it. I have open issue #2892 almost a month ago. It was a reason why I started working on "native" building system on Windows (NMake + Intel C++ Composer / Microsoft SDK) - there is very difficult to use GDB on Windows and thus I have not able to find out the problem behind this issue.

Cross-compiling worked fine for me in the past (before switching MinGW 4.8) and I recommend you to give it a try. In the case of success/failure report here - it will be interesting to know other's experience.

[vtjnash]

I don't see how #2892 is related at all. Debugging is broken because of #3031, which is an LLVM issue and won't be affected by switching to a different compiler.

(you probably are getting a null pointer segfault, but it's hard to say, and even harder to figure out why)

[vtjnash]

Actually, setting USE_SYSTEM_MPFR=1 will almost certainly cause the error that you see since mingw does not include libmpfr.dll

[vharavy]

@vtjnash You are right, again. It was a typo, I was referring to #2896. GitHub's auto-complete mixed up my post.

[vtjnash]

Ah, Github's autocomplete gets in my way too.

I just forced a check of my cross-compiled copy of mpfr with wine and it was fine. The printf tests that failed for me were preceded by warnings from wine that it was using unimplemented features of msvcrt.

[bsxfan]

My 32-bit Julia REPL is crashing on Windows at unpredictable times with

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.

I'm using a cross-compiled 32-bit version on Windows 7, using build a7c301f-WINNT-i686. The previous version that I used, 3ee9803-WINNT-i686 never gave that problem.

[quinnj]

As an update, I believe I've gotten MPFR to compile correctly (after reaching out to the mpfr team for some help). The adjustments I have to make are adding --disable-thread-safe CFLAGS="-D__USE_MINGW_ANSI_STDIO" to the deps/makefile for mpfr (tacked on the end of line 1217), and by taking out dont_link_with_gmp="yes" at line 367 in the deps/mpfr-3.1.2/configure.ac file (see the discussion here).

Unfortunately, though MPFR now compiles and passes tests, JULIA usr/lib/julia/sys.ji still produces the same error.

    CC ui/repl.o
    CC ui/repl-basic.o
    LINK usr/bin/julia-release-basic.exe
    CC ui/repl-readline.o
    LINK usr/bin/julia-release-readline.exe
    JULIA usr/lib/julia/sys.ji
Please submit a bug report with steps to reproduce this fault, and any error mes
sages that follow (in their entirety). Thanks.

*** This error is usually fixed by running 'make clean'. If the error persists,
try 'make cleanall'. ***

Any ideas on where to look next for solutions?

[vharavy]

@karbarcca I strongly recommend you to try cross-compilation. I have just cross-compiled a fresh version of Julia without any problems.

[quinnj]

@vharavy I'm already cross-compiling my current julia build. I would, however, really like to be able to build natively, so I'm letting that desire and the free-time I currently have to poke around and try to get things working. I think it only benefits everyone if various wrinkles get ironed out, right?

[vharavy]

@karbarcca In this case, feel free to poke around. You can find instructions how to run Julia under debugger at the beginning of discussion of issue #2896. Using GDB on Windows is a little bit tricky and requires a lot of patience, but if you have enough time you may find the problem.

[bsxfan]

Today is not a good Julia day South of the equator. We are not managing to compile on Linux (for Linux), because it uses git instructions our system does not have. Our windows cross-compile seems to work, but then REPL crashes as indicated above. I'm having to fall back on a build that is about 2 weeks old.

[JeffBezanson]

@StefanKarpinski @ViralBShah are we using git commands we weren't using 2 weeks ago?

[vtjnash]

I started a draft README of debugging julia on windows to add to the README.windows file. Please help me improve it!
https://gist.github.com/vtjnash/5623346

[ViralBShah]

@bsxfan What version of git are you using? I do not recollect any git related changes in the build.

[bsxfan]

@ViralBShah, thanks for the support.

1. On windows, we have switched to 64-bit. Our windows 64-bit build is now cross- compiling and running fine in the REPL. (The 32-bit REPL still crashes intermittently).
2. On our server the Julia build completes (and actually also runs Julia OK thereafter), but produces a git error message when setting the global VERSION because git version 1.6.0.6 does not have a "blame --dirty" option.

[ViralBShah]

I belive we prefer git 1.7. Is it possible to upgrade?

[quinnj]

With regards to the sysimg.jl fail, do we know if it's more related to julia/src compilation or a problem in deps?

I poked around the deps tests/checks last night and tried to rerun as many as I could find. A few results:

• unwind doesn't pass check
• git doesn't pass? (but this may be just a path problem on my system)
• llvm doesn't pass
• couldn't find a test for readline
• libuv doesn't pass
• openlibm doesn't pass
• couldn't find a test for random
• couldn't find a test for Rmath
• openblas/test freezes (thread-safe problem?)
• couldn't find test for atlas/lapack
• couldn't find test for suitesparse

Obviously there can be a ton of different things going on here, but I wasn't sure if anyone has any other input on the status of deps tests for windows.

[quinnj]

Thanks for pushing the fixes @vtjnash, can something be done about openlibm correctly detecting ARCH as well? I had to echo override ARCH=x86_64 >> Make.user to get it to build 64-bit, but it seems like this should auto-detect.

[vtjnash]

Ah, I missed the comment about ARCH. Since mingw is always 32-bit, uname -m will always return i686, but we in fact have a gcc cross compiler. The sane way to handle this is probably to ask gcc for the ARCH using gcc -dumpmachine

[vtjnash]

to whom it may concern: gcc on apple reports that its target ARCH is i686. this causes problems if you attempt to do USEGCC=1

[vtjnash]

@bsxfan the 32-bit build should now be fixed