I'm trying to get the Kaleidoscope tutorial mini compiler working on
Windows (as a trial run for developing a compiler using LLVM).
Kaleidoscope uses the C++ linkage method of code generation (as
opposed to spitting out intermediate code in a text or binary file),
which as I understand it is the preferred way of doing it for a few
reasons, one of them being that it gives you JIT capability, which in
turn lets you provide an interactive mode.
This requires compiling it with the LLVM headers, and presumably
libraries, which don't seem to be included in the Windows binary
distribution of LLVM, so presumably it is necessary to go to the
source distribution.
Is it necessary to compile the whole shebang from source, or would it
suffice/be easier to just compile the libraries? All the references I
could find with Google, discuss the first option.
According to c++ - How to build LLVM using GCC 4 on Windows? - Stack Overflow
it seems LLVM prefers to use MinGW 3.4.5 rather than 4.x, is this
correct?
http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx
discusses a procedure involving MinGW 3.4.5, is that the recommended
procedure? He mentions LLVM version 2.2, which is a few versions
behind the current release. Are the versions of the various components
of MinGW he mentions, still the preferred ones for working with LLVM
2.6?
Thanks to OvermindDL1 for pointing this out: compiling with Visual C++
actually works! Basically it's just a matter of running cmake (default
settings are fine) then nmake, and I've got what appears to be a
working version of LLVM.
Kaleidoscope crashes on attempting to exit with ^Z:
C:\llvm\bin>Kaleidoscope.exe
1+2;
Evaluated to 3.000000
3*4;
Evaluated to 12.000000
^Z
; ModuleID = 'my cool jit'
declare void @abort()
define double @0() {
entry:
ret double 3.000000e+000
}
define double @1() {
entry:
ret double 1.200000e+001
}
While deleting: double ()* %
An asserting value handle still pointed to this value!
UNREACHABLE executed at C:\d\llvm-2.6\lib\VMCore\Value.cpp:492!
I hope this is just a bug in Kaleidoscope itself, anyone got any idea?
I don't suppose anyone knows what (or how to find out what) the actual
command to compile Kaleidoscope is? I followed cmake/nmake down
through maybe half a dozen levels before getting lost, so I tried to
develop a compiler invocation from scratch. I got as far as
cl /EHsc /I\d\llvm-2.6\include /I\llvm\include /wd4355 toy.cpp
which successfully generated toy.obj and spat out 86 link time error
messages -- as expected, it needs the libraries specified.
cmakelists.txt says set(LLVM_LINK_COMPONENTS core jit interpreter
native) so I made a guess at the .lib file corresponding to the first
of these, and tried
cl /EHsc /I\d\llvm-2.6\include /I\llvm\include /wd4355 toy.cpp
\llvm\lib\llvmcore.lib
in the hope that the number of link time error messages would go
down... but it actually goes up to 395, and the earlier ones don't
obviously have anything to do with llvm itself. Any ideas? The first
few error messages are
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: __thiscall
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::~basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >(void)"
(??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ)
already defined in toy.obj
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: __thiscall
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >(class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > const &)"
(??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z)
already defined in toy.obj
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: __thiscall
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >(char const *)"
(??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z)
already defined in toy.obj
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: char const *
__thiscall std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::c_str(void)const "
(?c_str@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEPBDXZ)
already defined in toy.obj
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "public: static unsigned
int __cdecl std::char_traits<char>::length(char const *)"
(?length@?$char_traits@D@std@@SAIPBD@Z) already defined in toy.obj
Russell Wallace <russell.wallace@gmail.com> writes:
I don't suppose anyone knows what (or how to find out what) the actual
command to compile Kaleidoscope is? I followed cmake/nmake down
through maybe half a dozen levels before getting lost, so I tried to
develop a compiler invocation from scratch. I got as far as
cl /EHsc /I\d\llvm-2.6\include /I\llvm\include /wd4355 toy.cpp
which successfully generated toy.obj and spat out 86 link time error
messages -- as expected, it needs the libraries specified.
cmakelists.txt says set(LLVM_LINK_COMPONENTS core jit interpreter
native) so I made a guess at the .lib file corresponding to the first
of these, and tried
cl /EHsc /I\d\llvm-2.6\include /I\llvm\include /wd4355 toy.cpp
\llvm\lib\llvmcore.lib
in the hope that the number of link time error messages would go
down... but it actually goes up to 395, and the earlier ones don't
obviously have anything to do with llvm itself. Any ideas? The first
few error messages are
Sadly, nmake can't be told to show the full command they execute for
makefiles generated with cmake. Otherwise it would be obvious to know
the involved steps for building a component.
First of all, use /MDd (for debug builds) or /MD (for release builds) on
the command line. The required LLVM libraries can be listed using the
`llvm-config' script on Unix or MinGW. The dependencies are listed too
in
%LLVMSourceRoot%/cmake/modules/LLVMLibDeps.cmake
bus as this is a bit inconvenient to read, here they are for you:
-lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMMCParser
-lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMSelectionDAG
-lLLVMAsmPrinter -lLLVMX86Info -lLLVMInterpreter -lLLVMJIT
-lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine
-lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC
-lLLVMCore -lLLVMSupport -lLLVMSystem
Rename -lLIBRARYNAME to \llvm\lib\LIBRARYNAME.lib
HTH.
Thanks!
Three of the libraries are not found: LLVMX86Disassembler.lib
LLVMMCParser.lib LLVMInstCombine.lib ... the third one of those sounds
like it might be important, what does it do exactly?
But specifying the rest of them with /MD completes the build with this message
Creating library toy.lib and object toy.exp
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of
other libs; use /NODEFAULTLIB:library
And generates toy.exe; when I run this, and test it by typing 1+2; it
crashes with no error message. Any idea what the problem might be?
(Tried it again with /MDd, and the resulting toy.exe successfully
evaluates 1+2, though crashes as before when I exit with ^Z.)
Russell Wallace <russell.wallace@gmail.com> writes:
Three of the libraries are not found: LLVMX86Disassembler.lib
LLVMMCParser.lib LLVMInstCombine.lib ... the third one of those sounds
like it might be important, what does it do exactly?
A transformation pass. If the program works without it, I don't think it
is important unless you care about optimization.
It is strange that those libraries are absent from the build, though.
But specifying the rest of them with /MD completes the build with this message
Creating library toy.lib and object toy.exp
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of
other libs; use /NODEFAULTLIB:library
And generates toy.exe; when I run this, and test it by typing 1+2; it
crashes with no error message. Any idea what the problem might be?
Most likely this is due to mixing compiled code wich was built with
different settings. Most specifically, your LLVM libraries possibly are
a debug build, so /MDd (which links the debug-mode variant of the VC
runtime libraries) was used for them.
(Tried it again with /MDd, and the resulting toy.exe successfully
evaluates 1+2, though crashes as before when I exit with ^Z.)
Possibly some bug related to cleaning up memory on exit.
A transformation pass. If the program works without it, I don't think it
is important unless you care about optimization.
Ah, I was afraid of that, because I do care very much about
optimization -- it's the main reason I'm planning on using llvm for my
compiler backend in the first place.
Any guess at where to start investigating why LLVMInstCombine.lib
might be missing? If there had been an error during the attempt to
compile it, would the build process have stopped there, or just
skipped it and kept going new?
Most likely this is due to mixing compiled code wich was built with
different settings. Most specifically, your LLVM libraries possibly are
a debug build, so /MDd (which links the debug-mode variant of the VC
runtime libraries) was used for them.
That certainly sounds plausible. How do I build llvm in release mode?
The makefile generated by cmake doesn't include 'debug' and 'release'
targets.
Possibly some bug related to cleaning up memory on exit.
That seems plausible. If it's a bug in Kaleidoscope itself rather than
the libraries, it's not very important.
Russell Wallace <russell.wallace@gmail.com> writes:
A transformation pass. If the program works without it, I don't think it
is important unless you care about optimization.
Ah, I was afraid of that, because I do care very much about
optimization -- it's the main reason I'm planning on using llvm for my
compiler backend in the first place.
Any guess at where to start investigating why LLVMInstCombine.lib
might be missing? If there had been an error during the attempt to
compile it, would the build process have stopped there, or just
skipped it and kept going new?
nmake should stop. The IDE does not, although reports the number of
errors at the end.
Read http://www.llvm.org/docs/CMake.html for learning how to build LLVM
on the configuration you wish. Then, start anew. Watch the output of
nmake to see if those libraries are skipped.
That said, those libraries are new and not present on the last official
LLVM release. So, unless you are using a svn checkout, it is normal that
they are absent.
[snip]
Ah! I'm using the 2.6 release, so that explains that. I'll look for
them in 2.7 when that comes out.
And rereading the documentation on the cmake build process, yes,
that's where you set the release build; so I tried that just now, and
it works! toy.exe runs fine, it even fixes the crash on exit.
Thanks for the help! I'll probably be back with more questions once I
start getting my front-end code linked in 