[cmake] klee does not build without -fno-rtti #508

Closed
jirislaby opened this Issue Nov 20, 2016 · 21 comments

Comments

Projects
None yet
6 participants
@jirislaby
Contributor

jirislaby commented Nov 20, 2016

@delcypher: I use this llvm 3.4:
https://build.opensuse.org/package/show/home:jirislaby:statica/llvm34

And building of klee fails with:

: && /usr/bin/c++   -std=gnu++98 -Wall -Wextra -Wno-unused-parameter -O2 -g   tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o  -o bin/kleaver  -rdynamic lib/libkleaverSolver.a lib/libkleeBasic.a lib/libkleaverSolver.a lib/libkleeBasic.a lib/libkleaverExpr.a lib/libkleeSupport.a /usr/lib64/libstp.so.2.1.2 -lboost_program_options-mt -lminisat -lz -ltcmalloc /opt/llvm-3.4.2/lib/libLLVMSupport.so -L/opt/llvm-3.4.2/lib  -lrt -ldl -lpthread -Wl,-rpath,/opt/llvm-3.4.2/lib: && :
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xbf0): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xd08): undefined reference to `typeinfo for llvm::cl::generic_parser_base'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xd70): undefined reference to `typeinfo for llvm::cl::Option'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xdf8): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xf10): undefined reference to `typeinfo for llvm::cl::generic_parser_base'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xf70): undefined reference to `typeinfo for llvm::cl::Option'

and more.

I have to use:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -177,6 +177,7 @@ set(KLEE_COMPONENT_CXX_DEFINES "")
 set(KLEE_COMPONENT_CXX_FLAGS "")
 set(KLEE_SOLVER_LIBRARIES "")
 set(KLEE_COMPONENT_EXTRA_LIBRARIES "")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-rtti")
 
 ################################################################################
 # Find LLVM

Cmake should detect this somehow and pass -fno-rtti if needed. We actually can always?

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby The CMake build system is supposed to handle this. In the root CMakeLists.txt file there is this

###############################################################################
# RTTI
###############################################################################
if (NOT LLVM_ENABLE_RTTI)
  if (ENABLE_SOLVER_METASMT)
    message(WARNING "Not disabling RTTI because metaSMT uses them")
    # FIXME: Should this be FATAL_ERROR rather than ERROR?
    message(WARNING
      "This build configuration is not supported and will likely not work."
      "You should recompile LLVM with RTTI enabled.")
  else()
    klee_component_add_cxx_flag("-fno-rtti" REQUIRED)
  endif()
endif()

This suggests that LLVM_ENABLE_RTTI for your build is set to ON (or its equivalent).

During configure the value of LLVM_ENABLE_RTTI is shown

-- LLVM_CONFIG_BINARY: /home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin/llvm-config
-- LLVM_PACKAGE_VERSION: "3.4.2"
-- LLVM_VERSION_MAJOR: "3"
-- LLVM_VERSION_MINOR: "4"
-- LLVM_VERSION_PATCH: "2"
-- LLVM_DEFINITIONS: "-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS"
-- LLVM_ENABLE_ASSERTIONS: "ON"
-- LLVM_ENABLE_EH: "OFF"
-- LLVM_ENABLE_RTTI: "OFF"
-- LLVM_INCLUDE_DIRS: "/home/dan/dev/klee/llvm/llvm-3.4.2.src/include;/home/dan/dev/klee/llvm/build/include"
-- LLVM_LIBRARY_DIRS: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/lib"
-- LLVM_TOOLS_BINARY_DIR: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin"

The variable comes from cmake/find_llvm.cmake. You'll have to take a look at see what's going wrong.

If you're using the llvm-config binary (the default) rather than find_package(LLVM CONFIG) then the relevant code is:

  set(LLVM_ENABLE_ASSERTIONS ON)
  set(LLVM_ENABLE_EH ON)
  set(LLVM_ENABLE_RTTI ON)
  _run_llvm_config(_llvm_cxx_flags "--cxxflags")
  string_to_list("${_llvm_cxx_flags}" _llvm_cxx_flags_list)
  foreach (flag ${_llvm_cxx_flags_list})
    if ("${flag}" STREQUAL "-DNDEBUG")
      # Note we don't rely on `llvm-config --build-mode` because
      # that seems broken when LLVM is built with CMake.
      set(LLVM_ENABLE_ASSERTIONS OFF)
    elseif ("${flag}" STREQUAL "-fno-exceptions")
      set(LLVM_ENABLE_EH OFF)
    elseif ("${flag}" STREQUAL "-fno-rtti")
      set(LLVM_ENABLE_RTTI OFF)
    endif()
  endforeach()
Contributor

delcypher commented Nov 20, 2016

@jirislaby The CMake build system is supposed to handle this. In the root CMakeLists.txt file there is this

###############################################################################
# RTTI
###############################################################################
if (NOT LLVM_ENABLE_RTTI)
  if (ENABLE_SOLVER_METASMT)
    message(WARNING "Not disabling RTTI because metaSMT uses them")
    # FIXME: Should this be FATAL_ERROR rather than ERROR?
    message(WARNING
      "This build configuration is not supported and will likely not work."
      "You should recompile LLVM with RTTI enabled.")
  else()
    klee_component_add_cxx_flag("-fno-rtti" REQUIRED)
  endif()
endif()

This suggests that LLVM_ENABLE_RTTI for your build is set to ON (or its equivalent).

During configure the value of LLVM_ENABLE_RTTI is shown

-- LLVM_CONFIG_BINARY: /home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin/llvm-config
-- LLVM_PACKAGE_VERSION: "3.4.2"
-- LLVM_VERSION_MAJOR: "3"
-- LLVM_VERSION_MINOR: "4"
-- LLVM_VERSION_PATCH: "2"
-- LLVM_DEFINITIONS: "-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS"
-- LLVM_ENABLE_ASSERTIONS: "ON"
-- LLVM_ENABLE_EH: "OFF"
-- LLVM_ENABLE_RTTI: "OFF"
-- LLVM_INCLUDE_DIRS: "/home/dan/dev/klee/llvm/llvm-3.4.2.src/include;/home/dan/dev/klee/llvm/build/include"
-- LLVM_LIBRARY_DIRS: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/lib"
-- LLVM_TOOLS_BINARY_DIR: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin"

The variable comes from cmake/find_llvm.cmake. You'll have to take a look at see what's going wrong.

If you're using the llvm-config binary (the default) rather than find_package(LLVM CONFIG) then the relevant code is:

  set(LLVM_ENABLE_ASSERTIONS ON)
  set(LLVM_ENABLE_EH ON)
  set(LLVM_ENABLE_RTTI ON)
  _run_llvm_config(_llvm_cxx_flags "--cxxflags")
  string_to_list("${_llvm_cxx_flags}" _llvm_cxx_flags_list)
  foreach (flag ${_llvm_cxx_flags_list})
    if ("${flag}" STREQUAL "-DNDEBUG")
      # Note we don't rely on `llvm-config --build-mode` because
      # that seems broken when LLVM is built with CMake.
      set(LLVM_ENABLE_ASSERTIONS OFF)
    elseif ("${flag}" STREQUAL "-fno-exceptions")
      set(LLVM_ENABLE_EH OFF)
    elseif ("${flag}" STREQUAL "-fno-rtti")
      set(LLVM_ENABLE_RTTI OFF)
    endif()
  endforeach()
@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby I just noticed you're using CMake to build LLVM. That's a configuration I haven't tested so there might be something wrong or different about the way llvm-config behaves.

Contributor

delcypher commented Nov 20, 2016

@jirislaby I just noticed you're using CMake to build LLVM. That's a configuration I haven't tested so there might be something wrong or different about the way llvm-config behaves.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

Hmm, no -fno-rtti in the flags. It may also well be that llvm 3.4 does not emit that to flags.

$ llvm-config --cxxflags
-I/opt/llvm-3.4.2/include  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -fmessage-length=0 -grecord-gcc-switches -Og -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Let me investigate further.

Contributor

jirislaby commented Nov 20, 2016

Hmm, no -fno-rtti in the flags. It may also well be that llvm 3.4 does not emit that to flags.

$ llvm-config --cxxflags
-I/opt/llvm-3.4.2/include  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -fmessage-length=0 -grecord-gcc-switches -Og -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Let me investigate further.

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby Okay yeah here's the problem.

When you build LLVM 3.4 with CMake the llvm-config binary gives misleading output.

I can see LLVM is building itself with -fno-rtti. However the output of the generated llvm-config binary when built with CMake is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build_cmake/include 
-fPIC -fvisibility-inlines-hidden
-Wall
-W
-Wno-unused-parameter
-Wwrite-strings
-Wno-missing-field-initializers -pedantic
-Wno-long-long
-Wno-maybe-uninitialized
-Wnon-virtual-dtor
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS

but when llvm is built using the Autoconf/Makefile the output is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build/include
-D_DEBUG
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-O3 -fomit-frame-pointer
-g
-fvisibility-inlines-hidden
-fno-exceptions
-fno-rtti
-fPIC
-Woverloaded-virtual
-Wcast-qual

So this looks like a bug in LLVM 3.4

Contributor

delcypher commented Nov 20, 2016

@jirislaby Okay yeah here's the problem.

When you build LLVM 3.4 with CMake the llvm-config binary gives misleading output.

I can see LLVM is building itself with -fno-rtti. However the output of the generated llvm-config binary when built with CMake is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build_cmake/include 
-fPIC -fvisibility-inlines-hidden
-Wall
-W
-Wno-unused-parameter
-Wwrite-strings
-Wno-missing-field-initializers -pedantic
-Wno-long-long
-Wno-maybe-uninitialized
-Wnon-virtual-dtor
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS

but when llvm is built using the Autoconf/Makefile the output is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build/include
-D_DEBUG
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-O3 -fomit-frame-pointer
-g
-fvisibility-inlines-hidden
-fno-exceptions
-fno-rtti
-fPIC
-Woverloaded-virtual
-Wcast-qual

So this looks like a bug in LLVM 3.4

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby I think you might just have to build LLVM using the old build system when using 3.4. Unfortunately using the find_package(LLVM CONFIG) method won't work with LLVM 3.4 because it doesn't define all the variables we need. LLVM_ENABLE_EH, LLVM_ENABLE_RTTI and LLVM_ENABLE_ASSERTIONS variables didn't exist at that time.

Contributor

delcypher commented Nov 20, 2016

@jirislaby I think you might just have to build LLVM using the old build system when using 3.4. Unfortunately using the find_package(LLVM CONFIG) method won't work with LLVM 3.4 because it doesn't define all the variables we need. LLVM_ENABLE_EH, LLVM_ENABLE_RTTI and LLVM_ENABLE_ASSERTIONS variables didn't exist at that time.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

ugh, I am looking forward when #385 is merged. Thanks for checking.

Contributor

jirislaby commented Nov 20, 2016

ugh, I am looking forward when #385 is merged. Thanks for checking.

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby Unfortunately I can't think of a good way to fix this. If LLVM can't tell KLEE's build system that it was built with -fno-rtti then there's not much we can do.

Contributor

delcypher commented Nov 20, 2016

@jirislaby Unfortunately I can't think of a good way to fix this. If LLVM can't tell KLEE's build system that it was built with -fno-rtti then there's not much we can do.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor
commit 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
Author: Chris Bieneman <beanz@apple.com>
Date:   Fri Aug 14 16:20:31 2015 +0000

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti

and

$ git branch -r --contains 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
  origin/HEAD -> origin/master
  origin/master
  origin/release_38
  origin/release_39
  origin/stable
  origin/testing

suggest that only 3.8+ was fixed :/.

Contributor

jirislaby commented Nov 20, 2016

commit 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
Author: Chris Bieneman <beanz@apple.com>
Date:   Fri Aug 14 16:20:31 2015 +0000

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti

and

$ git branch -r --contains 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
  origin/HEAD -> origin/master
  origin/master
  origin/release_38
  origin/release_39
  origin/stable
  origin/testing

suggest that only 3.8+ was fixed :/.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

3.7 received that as a backport:

commit db381065aa57bcade0264dd8fdebf039adf0de8a
Author: Hans Wennborg <hans@hanshq.net>
Date:   Mon Aug 17 20:22:50 2015 +0000

    Merging r245064:
    ------------------------------------------------------------------------
    r245064 | cbieneman | 2015-08-14 09:20:31 -0700 (Fri, 14 Aug 2015) | 5 lines

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti
Contributor

jirislaby commented Nov 20, 2016

3.7 received that as a backport:

commit db381065aa57bcade0264dd8fdebf039adf0de8a
Author: Hans Wennborg <hans@hanshq.net>
Date:   Mon Aug 17 20:22:50 2015 +0000

    Merging r245064:
    ------------------------------------------------------------------------
    r245064 | cbieneman | 2015-08-14 09:20:31 -0700 (Fri, 14 Aug 2015) | 5 lines

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti
@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

In principle you should be able to use the find_package(LLVM CONFIG) method for getting information from LLVM for LLVM 3.5 and newer

https://github.com/llvm-mirror/llvm/blob/release_35/cmake/modules/LLVMConfig.cmake.in

so that would probably be the preferred way of interacting with newer LLVM versions if they were built with CMake.

Contributor

delcypher commented Nov 20, 2016

In principle you should be able to use the find_package(LLVM CONFIG) method for getting information from LLVM for LLVM 3.5 and newer

https://github.com/llvm-mirror/llvm/blob/release_35/cmake/modules/LLVMConfig.cmake.in

so that would probably be the preferred way of interacting with newer LLVM versions if they were built with CMake.

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

One possible solution is I could add a CMake option to force RTTI of ( a sort of "I know what I'm doing flag") which you could use.

It's not ideal though. In principle we'd need one for disable exception handling too.

Contributor

delcypher commented Nov 20, 2016

One possible solution is I could add a CMake option to force RTTI of ( a sort of "I know what I'm doing flag") which you could use.

It's not ideal though. In principle we'd need one for disable exception handling too.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

It's not about me, I backported the patch to llvm, so everything should be green for me... But for others, the flag would work.

Contributor

jirislaby commented Nov 20, 2016

It's not about me, I backported the patch to llvm, so everything should be green for me... But for others, the flag would work.

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

Given we do not need dynamic_cast and other slow crap, what prevents us from disabling rtti in klee completely? (Independently on llvm.)

Contributor

jirislaby commented Nov 20, 2016

Given we do not need dynamic_cast and other slow crap, what prevents us from disabling rtti in klee completely? (Independently on llvm.)

@jirislaby

This comment has been minimized.

Show comment
Hide comment
@jirislaby

jirislaby Nov 20, 2016

Contributor

Or doesn't llvm-rtti + klee-no-rtti combination fly?

Contributor

jirislaby commented Nov 20, 2016

Or doesn't llvm-rtti + klee-no-rtti combination fly?

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Nov 20, 2016

Contributor

@jirislaby I've never really used that combination (side note: I know that the LLVM packages in some distros build with RTTI enabled - e.g. Ubuntu/Debian).

I tried quickly now and it "seems to work" (just using Z3 and STP solvers).

For exceptions though we have to enable them for MetaSMT when that's enabled. Otherwise exceptions are disabled if they were disabled when LLVM was built.

I'm not sure if MetaSMT needs RTTI.

Contributor

delcypher commented Nov 20, 2016

@jirislaby I've never really used that combination (side note: I know that the LLVM packages in some distros build with RTTI enabled - e.g. Ubuntu/Debian).

I tried quickly now and it "seems to work" (just using Z3 and STP solvers).

For exceptions though we have to enable them for MetaSMT when that's enabled. Otherwise exceptions are disabled if they were disabled when LLVM was built.

I'm not sure if MetaSMT needs RTTI.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 23, 2017

I hit the same problem, following http://klee.github.io/build-llvm34/

I hit the same problem, following http://klee.github.io/build-llvm34/

@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Mar 23, 2017

Contributor

@pirapira This does not help very much. From above you can see the reason for the problem in @jirislaby 's case. If your scenario is exactly the same as his then you can follow his approach to solve this.

If your scenario is different you need to explain exactly what you did. Giving a link to http://klee.github.io/build-llvm34/ doesn't tell me anything because the build works following those instructions on my system, on macOS and in our Docker container.

Contributor

delcypher commented Mar 23, 2017

@pirapira This does not help very much. From above you can see the reason for the problem in @jirislaby 's case. If your scenario is exactly the same as his then you can follow his approach to solve this.

If your scenario is different you need to explain exactly what you did. Giving a link to http://klee.github.io/build-llvm34/ doesn't tell me anything because the build works following those instructions on my system, on macOS and in our Docker container.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira Mar 23, 2017

Yes, @jirislaby's approach worked for me.

Yes, @jirislaby's approach worked for me.

@ccadar ccadar added the build system label Jul 21, 2017

@lukeZhangMengxi

This comment has been minimized.

Show comment
Hide comment
@lukeZhangMengxi

lukeZhangMengxi Jul 28, 2017

Hi, I am quite new to this kind of stuff. I got the following errors when I try to make KLEE.
Is this a similar problem?
I tried adding "CXXFLAGS="-fno-rtti"" when I did the cmake, but I got the same errors.

[ 92%] Linking CXX executable ../../bin/kleaver
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `propogateValues(klee::Query const&, CexData&, bool, bool&) [clone .constprop.147]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `CexData::propogatePossibleValues(klee::ref<klee::Expr>, ValueRange)':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(IndependentSolver.cpp.o): In function `getIndependentConstraints(klee::Query const&, std::vector<klee::ref<klee::Expr>, std::allocator<klee::ref<klee::Expr> > >&) [clone .constprop.314]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::isCurrentDebugType(char const*)'
collect2: error: ld returned 1 exit status
tools/kleaver/CMakeFiles/kleaver.dir/build.make:105: recipe for target 'bin/kleaver' failed
make[2]: *** [bin/kleaver] Error 1
CMakeFiles/Makefile2:688: recipe for target 'tools/kleaver/CMakeFiles/kleaver.dir/all' failed
make[1]: *** [tools/kleaver/CMakeFiles/kleaver.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

lukeZhangMengxi commented Jul 28, 2017

Hi, I am quite new to this kind of stuff. I got the following errors when I try to make KLEE.
Is this a similar problem?
I tried adding "CXXFLAGS="-fno-rtti"" when I did the cmake, but I got the same errors.

[ 92%] Linking CXX executable ../../bin/kleaver
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `propogateValues(klee::Query const&, CexData&, bool, bool&) [clone .constprop.147]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `CexData::propogatePossibleValues(klee::ref<klee::Expr>, ValueRange)':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(IndependentSolver.cpp.o): In function `getIndependentConstraints(klee::Query const&, std::vector<klee::ref<klee::Expr>, std::allocator<klee::ref<klee::Expr> > >&) [clone .constprop.314]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::isCurrentDebugType(char const*)'
collect2: error: ld returned 1 exit status
tools/kleaver/CMakeFiles/kleaver.dir/build.make:105: recipe for target 'bin/kleaver' failed
make[2]: *** [bin/kleaver] Error 1
CMakeFiles/Makefile2:688: recipe for target 'tools/kleaver/CMakeFiles/kleaver.dir/all' failed
make[1]: *** [tools/kleaver/CMakeFiles/kleaver.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
@delcypher

This comment has been minimized.

Show comment
Hide comment
@delcypher

delcypher Jul 28, 2017

Contributor

@lukeZhangMengxi

/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'

This message is related to some internal debugging features in LLVM that we use. I don't think this is related to RTTI. Please open a new issue with more details information about your environment.

Contributor

delcypher commented Jul 28, 2017

@lukeZhangMengxi

/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'

This message is related to some internal debugging features in LLVM that we use. I don't think this is related to RTTI. Please open a new issue with more details information about your environment.

@MartinNowack

This comment has been minimized.

Show comment
Hide comment
@MartinNowack

MartinNowack Jul 12, 2018

Contributor

Let's close this one:

  • Documentation is up-to-date and explicitly warns to not build LLVM 3.4 with cmake.
  • Travis with Docker builds LLVM up to 3.7 with autoconf and uses cmake starting from 3.8
  • We build RTTI and non-RTTI versions to test the general case

Thanks for all the input.

Contributor

MartinNowack commented Jul 12, 2018

Let's close this one:

  • Documentation is up-to-date and explicitly warns to not build LLVM 3.4 with cmake.
  • Travis with Docker builds LLVM up to 3.7 with autoconf and uses cmake starting from 3.8
  • We build RTTI and non-RTTI versions to test the general case

Thanks for all the input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment