Paul Melis <llvm at assumetheposition.nl> writes:> Hi, just chiming in here... > > Óscar Fuentes wrote: >> [...] >> >> This is a simple guide for using cmake with LLVM: >> >> http://www.llvm.org/docs/CMake.html >> >> The makefiles distributed with LLVM have nothing to do with cmake. >>From the few times I tried building LLVM with CMake I got the impression > that it wasn't completely mature yet (the "TODO" sections in the page > you mention above reinforce that impression).What's immature is the documentation, mostly because it tries to go beyond what's really required. But on the other hand anyone who knows how to use cmake shouldn't need the documentation, except perhaps for the part that explains some variables specific to the LLVM build. (That part is complete). A TODO on the web page doesn't mean that the feature is missing. Cross compiling, for instance, should work (it worked when I tried months ago) but it is not documented. You need to read the cmake documentation for learning how to cross-compile. Right now the only fundamental thing missing on the cmake build spec is running the tests.> I remember at least one other build error in the past, related to > building a non-X86 backend. > > With current svn I get:[snip]> Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock' > ../../lib/libLLVMSystem.a(Mutex.cpp.o): In function > `llvm::sys::Mutex::Mutex(bool)':[snip] Thanks! Fixed. BTW, bug reports are welcome. -- Óscar
Hi Oscar, Óscar Fuentes wrote:> Paul Melis <llvm at assumetheposition.nl> writes: > > [snip] > > Thanks! Fixed. > > BTW, bug reports are welcome. >It seems that the llvm-config generated when building through CMake does not contain -lpthread on my 32-bit Core2Duo Gentoo Linux system (even though I configured with LLVM_ENABLE_PTHREADS). I get missing symbols during linking of e.g. the JIT tutorial code: 12:20|melis at juggle2:~> c++ -g tut2.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut2 /home/melis/llvm-cmake/lib/libLLVMSystem.a(Mutex.cpp.o): In function `llvm::sys::Mutex::tryacquire()': /home/melis/c/llvm-svn/lib/System/Mutex.cpp:144: undefined reference to `pthread_mutex_trylock' /home/melis/llvm-cmake/lib/libLLVMSystem.a(Mutex.cpp.o): In function `Mutex': /home/melis/c/llvm-svn/lib/System/Mutex.cpp:69: undefined reference to `pthread_mutexattr_init' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:75: undefined reference to `pthread_mutexattr_settype' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:80: undefined reference to `pthread_mutexattr_setpshared' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:88: undefined reference to `pthread_mutexattr_destroy' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:69: undefined reference to `pthread_mutexattr_init' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:75: undefined reference to `pthread_mutexattr_settype' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:80: undefined reference to `pthread_mutexattr_setpshared' /home/melis/c/llvm-svn/lib/System/Mutex.cpp:88: undefined reference to `pthread_mutexattr_destroy' collect2: ld returned 1 exit status Adding -lpthread to the compile command manually fixes it, but there seem to be some more discrepancies between the output of llvm-config for a build using ./configure and one using CMake: melis at juggle2:~/c/llvm-svn> ./configure --prefix=/home/melis/llvm --enable-optimized melis at juggle2:~/c/llvm-svn> make install melis at juggle2:~/c/llvm-svn> which llvm-config /home/melis/llvm/bin/llvm-config melis at juggle2:~/c/llvm-svn> llvm-config --cxxflags --ldflags --libs core -I/home/melis/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer -fPIC -Woverloaded-virtual -L/home/melis/llvm/lib -lpthread -ldl -lm -lelf -lLLVMCore -lLLVMSupport -lLLVMSystem melis at juggle2:~/c/llvm-svn-build> cmake /home/melis/c/llvm-svn -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/melis/llvm-cmake -DLLVM_ENABLE_THREADS=ON melis at juggle2:~/c/llvm-svn-build> make install melis at juggle2:~/c/llvm-svn-build> which llvm-config /home/melis/llvm-cmake/bin/llvm-config melis at juggle2:~/c/llvm-svn-build> llvm-config --cxxflags --ldflags --libs core -I/home/melis/llvm-cmake/include -O3 -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -L/home/melis/llvm-cmake/lib -lLLVMCore -lLLVMSupport -lLLVMSystem I'm actually also surprised about the _DEBUG versus NDEBUG difference... Paul
Paul Melis <llvm at assumetheposition.nl> writes:> It seems that the llvm-config generated when building through CMake does > not contain -lpthread on my 32-bit Core2Duo Gentoo Linux system (even > though I configured with LLVM_ENABLE_PTHREADS). I get missing symbols > during linking of e.g. the JIT tutorial code:[snip] This should be fixed now. Now about this one:> Adding -lpthread to the compile command manually fixes it, but there > seem to be some more discrepancies between the output of llvm-config for > a build using ./configure and one using CMake: > > melis at juggle2:~/c/llvm-svn> ./configure --prefix=/home/melis/llvm > --enable-optimized > melis at juggle2:~/c/llvm-svn> make install > melis at juggle2:~/c/llvm-svn> which llvm-config > /home/melis/llvm/bin/llvm-config > melis at juggle2:~/c/llvm-svn> llvm-config --cxxflags --ldflags --libs core > -I/home/melis/llvm/include -D_DEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fomit-frame-pointer > -fPIC -Woverloaded-virtual > -L/home/melis/llvm/lib -lpthread -ldl -lm -lelf > -lLLVMCore -lLLVMSupport -lLLVMSystem > > melis at juggle2:~/c/llvm-svn-build> cmake /home/melis/c/llvm-svn > -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/melis/llvm-cmake > -DLLVM_ENABLE_THREADS=ON > melis at juggle2:~/c/llvm-svn-build> make install > melis at juggle2:~/c/llvm-svn-build> which llvm-config > /home/melis/llvm-cmake/bin/llvm-config > melis at juggle2:~/c/llvm-svn-build> llvm-config --cxxflags --ldflags > --libs core > -I/home/melis/llvm-cmake/include -O3 -DNDEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -L/home/melis/llvm-cmake/lib > -lLLVMCore -lLLVMSupport -lLLVMSystem > > I'm actually also surprised about the _DEBUG versus NDEBUG difference...I'm surprised too. Question for those who know: why is _DEBUG and not NDEBUG defined on a --enable-optimize'd build? -- Óscar