> > 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. On Fri, May 29, 2015 at 10:32 AM, J Luis <[email protected]> wrote: > > > 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 > > >> >> On Fri, May 29, 2015 at 9:40 AM, J Luis <[email protected]> wrote: >> >>> Thanks. >>> Meanwhile I had to do a couple of dirty patches to reach this point but >>> probably they are specific of the MSYS2 build. >>> >>> sexta-feira, 29 de Maio de 2015 às 14:34:18 UTC+1, Isaiah escreveu: >>>> >>>> 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. >>>> >>>> On Fri, May 29, 2015 at 9:30 AM, J Luis <[email protected]> wrote: >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> quarta-feira, 27 de Maio de 2015 às 19:01:33 UTC+1, J Luis escreveu: >>>>>> >>>>>> >>>>>> >>>>>> 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? >>>>>> >>>>>> >>>>>>> On Mon, May 25, 2015 at 7:15 PM, J Luis <[email protected]> wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> segunda-feira, 25 de Maio de 2015 às 23:57:22 UTC+1, andrew cooke >>>>>>>> escreveu: >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> On Monday, 25 May 2015 17:38:47 UTC-3, J Luis wrote: >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> segunda-feira, 25 de Maio de 2015 às 20:33:11 UTC+1, J Luis >>>>>>>>>> escreveu: >>>>>>>>>>> >>>>>>>>>>> Ok, I'll start with it than. Thanks. >>>>>>>>>>> >>>>>>>>>>> segunda-feira, 25 de Maio de 2015 às 20:26:23 UTC+1, Keno >>>>>>>>>>> Fischer escreveu: >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure, I've never tried. The regular Julia makefile >>>>>>>>>>>> build usually works fine though. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, May 25, 2015 at 3:21 PM, J Luis <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 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? >>>>>>>>>>>>> >>>>>>>>>>>>> segunda-feira, 25 de Maio de 2015 às 20:07:08 UTC+1, Keno >>>>>>>>>>>>> Fischer escreveu: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, May 25, 2015 at 3:00 PM, J Luis <[email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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) >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>> >>
