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
>
> On Fri, May 29, 2015 at 10:32 AM, J Luis <[email protected] <javascript:>>
> 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)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
