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.
On Tue, May 26, 2015 at 1:15 PM J Luis <[email protected]> wrote: > 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' > > > terça-feira, 26 de Maio de 2015 às 00:38:34 UTC+1, Isaiah 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). >> > >> 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) >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>
