Cxx on Windows?

[J Luis]

Does it worth trying or it's known that it won't work? (I could try to build LLVM SVN with VS, if that helps)

[Keno Fischer]

I don't think anybody has ever tried. It shouldn't be too hard to make work, but will definitely require some modifications to Cxx.jl.

[J Luis]

OK, I may try one of these days but what would guess would the best way to build LLVM? Will it be expected to work with a VS build?

[Keno Fischer]

I'm not sure, I've never tried. The regular Julia makefile build usually works fine though.

[J Luis]

Ok, I'll start with it than. Thanks.

[J Luis]

Hmm, I~m confused with this error. What failed?

OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE)

  OS               ... WINNT
  Architecture     ... x86_64
  BINARY           ... 64bit
  Use 64 bits int    (equivalent to "-i8" in Fortran)
  C compiler       ... GCC  (command line : gcc -m64)
  Fortran compiler ... GFORTRAN  (command line : gfortran -m64)
  Library Name     ... libopenblasp-r0.2.14.a (Multi threaded; Max num-threads is 16)

To install the library, you can run "make PREFIX=/path/to/your/installation install".

Makefile:49: recipe for target 'julia-deps' failed
make: *** [julia-deps] Error 2

[andrew cooke]

if you run make again, do you get a more helpful error?  if it's running multiple threads sometimes the logging is confused and erstarting (and immediately hitting the error) is helpful.

[J Luis]

Thanks. Running make again let me advance a bit more but now I get tons of errors of this type

Cannot export ZN4llvm8DenseMapIPKNS_5ValueENS_19SelectionDAGBuilder17DanglingDebugInfoENS_12DenseMapInfoIS3_EENS_6detail12DenseMapPairIS3_S5_EEE4growEj: symbol not defined
Cannot export ZN4llvm8DenseMapIPKNS_5ValueENS_3ISD8NodeTypeENS_12DenseMapInfoIS3_EENS_6detail12DenseMapPairIS3_S5_EEE4growEj: symbol not defined

So, it seams that build LLVM SVN is not straightforward with MSYS2.

[Isaiah Norton]

Unless something has changed in the past month, the biggest issue with the recommended Make.user options is that LLDB uses some C++11 features that are not supported by GCC on Windows (call_once and some other mutex-related stuff).

https://github.com/Keno/Cxx.jl/issues/62#issuecomment-93184018

However, I'm not sure if LLDB is strictly necessary for the Clang-only functionality (I do remember some linking errors without it, but that was a number of months ago).

[Tony Kelman]

Would a posix-threads instead of win32-threads build of MinGW-w64 be worth trying here?

[J Luis]

After applying Keno's patch I now get only these two unresolved symbols error.

llvm[3]: Linking Release+Asserts Shared Library LLVM-3.7svn.dll
V:/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/lib/libLLVMSupport.a(COM.o):COM.cpp:(.text+0x16): undefined reference to `__imp_CoInitializeEx'
V:/julia/deps/llvm-svn/build_Release+Asserts/Release+Asserts/lib/libLLVMSupport.a(COM.o):COM.cpp:(.text+0x23): undefined reference to `__imp_CoUninitialize'

[Jameson Nash]

That looks like it might be a name-mangling error. In particular, they should not have been mangled, but they instead got mangled as if they were decorated with DLLEXPORT.

[J Luis]

Hmm, unless this (in llvm-pdbdump.cpp) somehow does that name mangling

::CoInitializeEx(nullptr, Coinit);

There is no DLLEXPORT decorations to any of those two.

[J Luis]

Just a follow up. I managed to build yesterday's LLVM SVN (today it's broken) with Visual Studio but when I try to use that as USE_SYSTEM_LLVM=1 than I get lots of g++ errors.
So I'm defeated on this.

[J Luis]

Unless something has changed in the past month, the biggest issue with the recommended Make.user options is that LLDB uses some C++11 features that are not supported by GCC on Windows (call_once and some other mutex-related stuff).

https://github.com/Keno/Cxx.jl/issues/62#issuecomment-93184018

However, I'm not sure if LLDB is strictly necessary for the Clang-only functionality (I do remember some linking errors without it, but that was a number of months ago).

OK, insisted a bit more using a avoid the problems strategy I managed to build llvm but than hit the 'call_once' problem you mentioned. Restarted this time with

 BUILD_LLDB=0

and ...

V:/julia/deps/llvm-svn/tools/lldb/source/API/SBValue.cpp:1663:38: warning: unknown conversion type character 'l' in format [-Wformat=]
                      addr.GetOffset());
                                      ^
V:/julia/deps/llvm-svn/tools/lldb/source/API/SBValue.cpp:1663:38: warning: too many arguments for format [-Wformat-extra-args]
llvm[6]: Building Release+Asserts Archive Library liblldbAPI.a
/v/julia/deps/llvm-svn/Makefile.rules:880: recipe for target 'all' failed
make[4]: *** [all] Error 1

so, it's still trying to build LLDB. Is this the linking errors you were referring?

[J Luis]

Anyone (not many, I'm afraid) can give me an hint on what I could try to fix this error? It seams that I'm nearly there but can't get over this one by myself.

My goal with this is that I would like to play a bit with Qt.

Thanks

    CC src/codegen.o
codegen.cpp: In function 'llvm::Value* emit_expr(jl_value_t*, jl_codectx_t*, bool, bool, jl_sym_t**)':
codegen.cpp:3229:59: error: no matching function for call to 'llvm::IRBuilder<>::CreateCall(llvm::Value*)'
         builder.CreateCall(prepare_call(resetstkoflw_func));
                                                           ^
codegen.cpp:3229:59: note: candidates are:
In file included from codegen.cpp:55:0:
V:/julia/usr/include/llvm/IR/IRBuilder.h:1468:13: note: llvm::CallInst* llvm::IRBuilder<preserveNames, T, Inserter>::CreateCall(llvm::Value*, llvm::ArrayRef<llvm::Value*>, const llvm::Twine&) [with bool preserveNames = true; T = llvm::ConstantFolder; Inserter = llvm::IRBuilderDefaultInserter<true>]
   CallInst *CreateCall(Value *Callee, ArrayRef<Value *> Args,
             ^
V:/julia/usr/include/llvm/IR/IRBuilder.h:1468:13: note:   candidate expects 3 arguments, 1 provided
V:/julia/usr/include/llvm/IR/IRBuilder.h:1473:13: note: llvm::CallInst* llvm::IRBuilder<preserveNames, T, Inserter>::CreateCall(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, const llvm::Twine&) [with bool preserveNames = true; T = llvm::ConstantFolder; Inserter = llvm::IRBuilderDefaultInserter<true>]
   CallInst *CreateCall(llvm::FunctionType *FTy, Value *Callee,
             ^
V:/julia/usr/include/llvm/IR/IRBuilder.h:1473:13: note:   candidate expects 4 arguments, 1 provided
V:/julia/usr/include/llvm/IR/IRBuilder.h:1478:13: note: llvm::CallInst* llvm::IRBuilder<preserveNames, T, Inserter>::CreateCall(llvm::Function*, llvm::ArrayRef<llvm::Value*>, const llvm::Twine&) [with bool preserveNames = true; T = llvm::ConstantFolder; Inserter = llvm::IRBuilderDefaultInserter<true>]
   CallInst *CreateCall(Function *Callee, ArrayRef<Value *> Args,
             ^
V:/julia/usr/include/llvm/IR/IRBuilder.h:1478:13: note:   candidate expects 3 arguments, 1 provided

[Isaiah Norton]

I was looking yesterday at the issue you opened about this. Let me see if LLVM finally finished compiling and I will push my fix if so.

[J Luis]

Thanks.
Meanwhile I had to do a couple of dirty patches to reach this point but probably they are specific of the MSYS2 build.

[Isaiah Norton]

Fixed. Regarding the other one you mentioned:

(.text+0x23): undefined reference to `__imp_CoUninitialize'

Maybe you tried/corrected this already, but for future reference the issue here is that the LLVM shared library version apparently (now?) needs to link to ole32. I was able to work around this by running `make VERBOSE=1` and then copying and re-running the last (failing) g++ command string `-lole32` added at the end. I guess we could try to get a patch in, but it's going to be continual whack-a-mole because LLVM does not support this build configuration.

[J Luis]

Fixed. Regarding the other one you mentioned:

Thanks. It builds here too but did not try it any further (I had tried with a NULL instead of a '{ }'). But still regarding my issue, was I wrong to assume that "#ifdef LLVM37" condition (line 3204) should also apply to Windows (currently it applies only to NO-WINDOWS)?
 

(.text+0x23): undefined reference to `__imp_CoUninitialize'

Maybe you tried/corrected this already, but for future reference the issue here is that the LLVM shared library version apparently (now?) needs to link to ole32. I was able to work around this by running `make VERBOSE=1` and then copying and re-running the last (failing) g++ command string `-lole32` added at the end. I guess we could try to get a patch in, but it's going to be continual whack-a-mole because LLVM does not support this build configuration.

No, by patch was much brute force. Since it happens in a code that apparently is only for dumping PDB files, I simple commented the call to those functions.
I did however find that the problem is due to a miss linkage to ole32 but got lost with where to fix when I found that the llvm-svn/lib/Support/CmakeList.txt has

if( NOT MSVC )
  if( MINGW )
    set(system_libs ${system_libs} imagehlp psapi shell32 ole32)
  elseif( CMAKE_HOST_UNIX )

 so it should be linking against ole32
 

[Isaiah Norton]

But still regarding my issue, was I wrong to assume that "#ifdef LLVM37" condition (line 3204) should also apply to Windows (currently it applies only to NO-WINDOWS)? 

It intentionally does not apply to Windows because the call arguments there are different on Windows.

I did however find that the problem is due to a miss linkage to ole32 but got lost with where to fix when I found that the llvm-svn/lib/Support/CmakeList.txt has

Long-term we will be better off (at least re: LLVM) when we switch to CMake because LLVM people are more actively supporting that build system.

[J Luis]

sexta-feira, 29 de Maio de 2015 às 15:41:58 UTC+1, Isaiah escreveu:

But still regarding my issue, was I wrong to assume that "#ifdef LLVM37" condition (line 3204) should also apply to Windows (currently it applies only to NO-WINDOWS)? 

It intentionally does not apply to Windows because the call arguments there are different on Windows.

Ok, thanks for the info.
 

I did however find that the problem is due to a miss linkage to ole32 but got lost with where to fix when I found that the llvm-svn/lib/Support/CmakeList.txt has

Long-term we will be better off (at least re: LLVM) when we switch to CMake because LLVM people are more actively supporting that build system.

Ah, I see. We are not using the CMake solution so the linking to ole32 was not actually done.

BTW, I tested my Julia+LLVM37 build and it  failed this test (Julia+LLVM33 passes all tests)

        From worker 4:       * linalg3             /bin/sh: line 1:  5292 Segmentation fault      /v/julia/usr/bin/julia.exe --check-bounds=yes --startup-file=no ./runtests.jl all
Makefile:9: recipe for target 'all' failed

 

[J Luis]

I don't think anybody has ever tried. It shouldn't be too hard to make work, but will definitely require some modifications to Cxx.jl.

Well, I guess it does. It stops immediately with

julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: V:\julia\usr\bin
=====================================================[ ERROR: Cxx ]=====================================================


LoadError: could not spawn `make -f BuildBootstrap.Makefile 'JULIA_HOME=V:\julia\usr\bin'`: no such file or directory (E
NOENT)
while loading C:\j\.julia\v0.4\Cxx\deps\build.jl, in expression starting on line 16

 

[Tony Kelman]

I'm guessing you'll either need to translate https://github.com/Keno/Cxx.jl/blob/master/deps/BuildBootstrap.Makefile into cmake, or run julia from within a posix environment that has gmake available.

[J Luis]

Sorry, I'm being to impulsive with my reports. After posting I realized that I tried to run the build from within the Windows cmd that knows nothing about 'make'

When run from the MSYS2 bash (the same one that build julia itself) the error is:

julia> Pkg.build("Cxx")
ERROR: failed process: Process(`git '--work-tree=C:\j\.julia\v0.4\Cxx' '--git-dir=C:\j\.julia\v0.4\Cxx\.git' update-index -q --really-refresh`, ProcessExited(128)) [128]
 in run at <invalid>
 in success at .\pkg\git.jl:32

[Tony Kelman]

Oh, right, and that one is probably because Pkg doesn't work properly with a posix-style git in msys or cygwin, it only works with a mingw-style git like the one we bundle. So it's lose-lose until Cxx.jl converts to cmake, or Julia switches to libgit2 (which is coming along well but probably won'y be quite ready in time for 0.4), or we fix this git bug. The git bug might not be too hard to fix, what do you get when you run that git '--work-tree=C:\j\.julia\v0.4\Cxx' '--git-dir=C:\j\.julia\v0.4\Cxx\.git' update-index -q --really-refresh command manually in MSYS2 bash?

[Isaiah Norton]

You can just comment that out and run make manually first...

[J Luis]

sexta-feira, 29 de Maio de 2015 às 17:21:51 UTC+1, Tony Kelman escreveu:

Oh, right, and that one is probably because Pkg doesn't work properly with a posix-style git in msys or cygwin, it only works with a mingw-style git like the one we bundle. So it's lose-lose until Cxx.jl converts to cmake, or Julia switches to libgit2 (which is coming along well but probably won'y be quite ready in time for 0.4), or we fix this git bug. The git bug might not be too hard to fix, what do you get when you run that git '--work-tree=C:\j\.julia\v0.4\Cxx' '--git-dir=C:\j\.julia\v0.4\Cxx\.git' update-index -q --really-refresh command manually in MSYS2 bash?

it gives no error but seams to do nothing as well.

Isaiah, comment out what?
When I try to run manually from within ...
 

~> cd .julia/v0.4/Cxx/deps/
~/.julia/v0.4/Cxx/deps> make -f BuildBootstrap.Makefile JULIA_HOME=$JULIA_HOME
BuildBootstrap.Makefile:2: /../../deps/Versions.make: No such file or directory
BuildBootstrap.Makefile:3: /../../Make.inc: No such file or directory

[J Luis]

OK, more news. The MSYS2 git was being stubborn in getting out of the way (even when I prepended another one (a Windows portable git) in the path. So I moved it out of the way (renamed it) and now I think I can scream VVVVV ... and go home.

Thanks for all your help (but don't go away).

julia> Pkg.build("Cxx")
INFO: Building Cxx
Tuning for julia installation at: V:\julia\usr\

bin
    CC /c/j/.julia/v0.4/Cxx/deps/build/bootstrap.o
../src/bootstrap.cpp:1:0: warning: -fPIC ignored for target (all code is position independent)
 #undef B0 //rom termios
 ^
    LINK /c/j/.julia/v0.4/Cxx/deps/usr/lib/libcxxffi.dll
Not building debug library because corresponding julia DEBUG library does not exist.
To build, simply run the build again once the library at
V:/julia/usr/bin/../../usr/lib/libjulia-debug.dll
has been built.