Trouble with 64 bit Build on Windows

[joa-quim]

OK, I followed the instructions in README.windows exactly but it errors at

CC src/codegen.o
In file included from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\x86_64-w64-mingw32\bits\gthr-default.h:35:0,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\x86_64-w64-mingw32\bits\gthr.h:148,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\ext\atomicity.h:33,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\bits\ios_base.h:39,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\ios:42,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\ostream:38,
from c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\iterator:64,
from c:/programs/julia64/deps/llvm-3.2/include/llvm/ADT/SmallVector.h:25,
from c:/programs/julia64/deps/llvm-3.2/include/llvm/ExecutionEngine/ExecutionEngine.h:19,
from codegen.cpp:24:
julia.h:858:22: error: expected unqualified-id before '{' token
DLLEXPORT struct tm* localtime_r(const time_t *t, struct tm *tm);
^

[vtjnash]

I just followed the instructions, from a clean environment, and did not have an issue. The last two lines of the error log you provide make absolutely no sense to me. What do the referenced lines look like in your environment. Are you sure you didn't have some old build state lying around?

[joa-quim]

line 858 is the one with the call to localtime_r and yes, this is on an updated source tree.

#ifdef _OS_WINDOWS_
DLLEXPORT struct tm* localtime_r(const time_t *t, struct tm *tm);
#endif

and gcc

/c/programs/julia64> gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW64\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/temp/x64-480-posix-seh-r2/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-host-libstdcxx='-static -lstdc++' --with-libiconv --with-system-zlib --with-gmp=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-mpfr=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-mpc=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-isl=/temp/mingw-prereq/x86_64-w64-mingw32-static --with-cloog=/temp/mingw-prereq/x86_64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='rev2, Built by MinGW-builds project' --with-bugurl=http://sourceforge.net/projects/mingwbuilds/ CFLAGS='-O2 -pipe -I/temp/x64-480-posix-seh-r2/libs/include -I/temp/mingw-prereq/x64-zlib/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/temp/x64-480-posix-seh-r2/libs/include -I/temp/mingw-prereq/x64-zlib/include -I/temp/mingw-prereq/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/temp/x64-480-posix-seh-r2/libs/lib -L/temp/mingw-prereq/x64-zlib/lib -L/temp/mingw-prereq/x86_64-w64-mingw32-static/lib -L/temp/x64-480-posix-seh-r2/mingw64/opt/lib'
Thread model: posix
gcc version 4.8.0 (rev2, Built by MinGW-builds project)

[vtjnash]

I don't mean just that it is up-to-date (although posting your git sha1 would be more helpful), I mean that after switching compiler versions, you should delete everything that has previously been compiled (make distclean should generally be sufficient). Also, you are getting a C++ error on what should be a C header, and a very non-sensical backtrace. This backtrace appears to state that c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\x86_64-w64-mingw32\bits\gthr-default.h:35:0 contains the line #include "julia.h" on line 35, so you will hopefully understand my confusion when I say that I don't have the issue.
This means any of:
(1) you have files around (in your path and/or julia directory) that were processed by a different version of gcc
(2) some race condition in gcc has resulted in complete nonsense coming from the preprocessor
(3) your C:/MinGW files are corrupted
(4) git status reports that you have changed files
or
(5) something else is wrong
(6) I have no idea what I'm talking about

[joa-quim]

I had done a 'make distclean' before but for leaving no doubts I ripped the dir and started from a fresh. Unfortunately it made no difference at all. Note that the line

c:\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\c++\x86_64-w64-mingw32\bits\gthr-default.h:35:0

includes pthreads.h and that's where it all starts ending in the error on the localtime_r() call. I searched google with

"struct tm* localtime_r(const time_t *t, struct tm *tm);"

and other people have had the some problem, though the reports are about 2011 and refer to a localtime_r bug. If I comment the line 858 in julia.h (the one that calls localtime_r) than the building work proceeds a bit more but stops with a linking error that, curiously, is the same as when we do not do the first patch mentioned in the errata.

LINK usr/lib/libjulia-release.dll
c:/programs/julia64/usr/lib/libLLVMJIT.a(JIT.o):JIT.cpp:(.text+0x44af): undefined reference to __register_frame' c:/programs/julia64/usr/lib/libLLVMJIT.a(JIT.o):JIT.cpp:(.text+0x44c0): undefined reference to__deregister_frame'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/programs/julia64/usr/lib/libLLVMJIT.a(JIT.o): bad reloc address 0x0 in section `.pdata$_ZN4llvm15ExecutionEngine14finalizeObjectEv'

I honestly do not know what else to do. This is the same machine where I managed to build with the 'doomed' w32 gcc compiler and all paths are set by a batch that calls the mingw shell to minimize to the maximum the path contamination risk.

[vtjnash]

Ah, I didn't look closely enough at this comment in your gcc: Thread model: posix
It is an unfortunate fact that Sourceforge insists on recommending the wrong version of mingw in big bold letters on the same page as the version that I linked to in the README. The preferred thread model is win32, because it claims to produce faster code.

It seems like you lost the patch mentioned in the errata, presumably when you did the make distclean. You should be able to apply that fix now and delete usr to force a minimal rebuild.

I thought you would need to add #undef localtime_r after #include <time.h> in order to build jl_uv.h, instead of deleting the section?

[joa-quim]

OK, So I removed the posix and installed the win32. Now I get (and I've been here before. No point in doing clean or cleanall)

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 messages that follow (in their entirety). Thanks.

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

[vtjnash]

Just to be clear, you've switched compilers again so you did make distclean? But yeah, that's where my native windows 64 build fails too.

[joa-quim]

Yes and yes.

[vtjnash]

This may be a good deal more annoying than I had initially anticipated. The problem is the 64-bit build is still technically a cross-compile. So LLVM configures itself for the i686 "native" platform, resulting in segfaults as it truncates pointers (and messes up the calling conventions).

[quinnj]

I've thought it was an LLVM bug, because I've yet to be successful in getting any LLVM tests to pass for me.

[vtjnash]

It's not really an LLVM bug, just a configuration mistake. There has been a lot of noise on google about the best way to "fix" this problem but no resolution has been settled on. Unless you have further thoughts, I am going to "fix" this by adding another errata to the README.windows file noting that a native windows-64 build is still considered cross-compiling and requires adding "override XC_HOST = x86_64-w64-mingw32" to Make.user to be successful (this is the resolution typically recommended). I have removed my build state (git clean -fdx) to test my theory. I recommend you do the same, to ensure the other libraries are also configured properly.

(optionally, the user can also add override OPENBLAS_DYNAMIC_ARCH = 0 to speed up the build, assuming they don't plan to distribute the build to other computers)

[quinnj]

You're right; bad language on my part. I'll try a fresh build again tomorrow and report back.

[vtjnash]

Meh, it doesn't work either since the ar binary is called x86_64-w64-mingw32-gcc-ar (the gcc part shouldn't be there)

[vtjnash]

I'm tempted to just force --build=gcc -dumpmachine --target=gcc -dumpmachine --host=gcc -dumpmachine``. But I don't even know if that would work.

[joa-quim]

Sorry, still no good. I still get. And pardon me saying, but why closing the issues without the issue reporter confirm that it is solved?

    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 messages that follow (in their entirety). Thanks.

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

[pao: formatting]

[pao]

Note that this was an autoclose from the commit message (which contains the string fix #3242.) Reopening.

[vtjnash]

@joa-quim Did you do git clean -fdx && make? The build ran fine on my machine. I can't reproduce your error given only the information you have supplied. Also, what commit are you on?

Issues are connected to the commit messages to keep track of how issues got fixed. GitHub provides the Comment & Reopen button to make it easy (e.g. it is expected that you will reopen the bug if it isn't completely fixed)

[joa-quim]

No I hadn't done "clean -fdx", only "cleanall". But now that I did I get

LINK usr/lib/libjulia-release.dll
make[2]: *** No targets specified and no makefile found.  Stop.

Before trying to rebuild I always update to latest which now is: a0fa4a2
but I notice from my TurtoiseGit that there are lots of red dots in my julia tree, meaning local modifications that I did not do. Namely, the 'extras' directory is empty. It seams that git clean -fdx clean more that was restored later with a git pull and maybe that explains the "no makefile found".

And about the Reopen button, i don't see it. Only these two: "Close & Comment" & "Comment"

[joa-quim]

Right, looking into the git man I found the git restore and after it the make run till the end and this time with no errors.
Thanks.

[joa-quim]

Just a PS. Now that I closed the issue I can see a Reopen button.