llvm dev - Jun 2009 - [LLVMdev] CMake build maturity

Paul Melis wrote:
> Óscar Fuentes wrote:
>   
>> 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?
>>   
>>     
> I guess to keep all the assertions around. I think you need
> --disable-assertions to make those go away as well.
>   
Just checked: yup, there's plenty of assert()'s in the headers, so
-D_DEBUG will keep those alive.

Interestingly, when configuring with --enable-optimized and
--disable-assertions the resulting compilation calls itself a
"Release-Asserts build" while all asserts are thrown away, hmmm :)

Paul

Paul Melis wrote:
> Just checked: yup, there's plenty of assert()'s in the headers, so
> -D_DEBUG will keep those alive.
> 
> Interestingly, when configuring with --enable-optimized and
> --disable-assertions the resulting compilation calls itself a
> "Release-Asserts build" while all asserts are thrown away, hmmm
:)
Yeah, that's "Release-Asserts" as in "Release minus
asserts".

This has caused confusion before...

Frits van Bommel <fvbommel at wxs.nl> writes:
> Paul Melis wrote:
>> Just checked: yup, there's plenty of assert()'s in the headers,
so
>> -D_DEBUG will keep those alive.
>> 
>> Interestingly, when configuring with --enable-optimized and
>> --disable-assertions the resulting compilation calls itself a
>> "Release-Asserts build" while all asserts are thrown away,
hmmm :)
>
> Yeah, that's "Release-Asserts" as in "Release minus
asserts".
>
> This has caused confusion before...
Committed a change for the cmake build that implements the option
LLVM_ENABLE_ASSERTS. Defaults to ON if and only if CMAKE_BUILD_TYPE is
Release.

-- 
Óscar