Build issues (various): automatic configuration?

[prajjwald]

First: Thanks for sharing great examples: I'm going through these and trying to get hands on experience with using clang refactoring tools. I had to spend several days trying to get CoARCT to build correctly on my local virtual machine (ubuntu 17.04/16.04 - used both), clang/llvm 4.0 package installations (not local builds, though I tried both to get the build working), boost and google test (packages, not local builds).

The summary of changes I had to do to get things working on my machine were:

• re-arrange the APPEND_CLANG_LIB statements, so that the symbols were found. I can share the order that worked for me as a comment to this thread.
• target_link_libraries: add a BOOST_REGEX_LIB variable to find the boost_regex library and add it to various test/CMakeLists.txt near end of linkline
• target_link_libraries: add the dl library after z in each CMakeLists.txt (I'm not sure which ones actually needed it, but I was getting errors in more than one directory
• add a statement: set(CMAKE_CXX_STANDARD 14, as the CMAKE_CXX_FLAGS(... -std=c++14...) currently in the CMakeLists.txt did not seem to work
• add a -pthread option to CMAKE_CXX_FLAGS
• Remove the -search_paths_first flag from LLVM_LDFLAGS - while my binaries were linking correctly, they were segfaulting as soon as they ran, and gdb was not giving me any meaningful callstack. The error ld had been giving me had been: /usr/bin/ld: warning: cannot find entry symbol 'arch_paths_first'. As soon as I got rid of this flag: I was able to get the error to go away, and my binaries no longer segfaulted.

I did have to go on a bit of a wild goose chase looking into -frtti vs -fnortti flags, a my initial searches for the link errors (symbol not found) pointed towards these flags. Later, I found it was just the linkline order that was the cause.

I wasn't sure of how to list out the various issues I ran into and had to address to get my build to run, but I wanted to let you know of these. I'm pretty unfamiliar with both cmake and clang as of now, so I just wanted to point out what I ran into. In the long run, I think it might also be a good idea to somehow leverage llvm-configure, no? Once again, thanks for the code: I'm finally able to slowly go through it and play around :)!

[prajjwald]

APPEND_CLANG_LIB order that worked for me:

APPEND_CLANG_LIB(clangFrontend)
APPEND_CLANG_LIB(clangFrontendTool)
APPEND_CLANG_LIB(clangSerialization)
APPEND_CLANG_LIB(clangParse)
APPEND_CLANG_LIB(clangSema)
APPEND_CLANG_LIB(clangAST)
APPEND_CLANG_LIB(clangEdit)
APPEND_CLANG_LIB(clangLex)
APPEND_CLANG_LIB(clangAnalysis)
APPEND_CLANG_LIB(clangBasic)
APPEND_CLANG_LIB(clangDriver)
APPEND_CLANG_LIB(clangFormat)
APPEND_CLANG_LIB(clangASTMatchers)
APPEND_CLANG_LIB(clangToolingCore)
APPEND_CLANG_LIB(clangRewrite)
APPEND_CLANG_LIB(clangRewriteFrontend)
APPEND_CLANG_LIB(clangStaticAnalyzerFrontend)
APPEND_CLANG_LIB(clangStaticAnalyzerCheckers)
APPEND_CLANG_LIB(clangStaticAnalyzerCore)
APPEND_CLANG_LIB(clangTooling)
APPEND_CLANG_LIB(clangFrontend)

APPEND_CLANG_LIB(LLVMAnalysis)
APPEND_CLANG_LIB(LLVMMCParser)
APPEND_CLANG_LIB(LLVMMC)
APPEND_CLANG_LIB(LLVMBitReader)
APPEND_CLANG_LIB(LLVMProfileData)
APPEND_CLANG_LIB(LLVMOption)
APPEND_CLANG_LIB(LLVMSupport)
APPEND_CLANG_LIB(LLVMCore)
APPEND_CLANG_LIB(LLVMDemangle)

[timmah]

Thank you for your comments. I think llvm-config is the solution. I am overdue for a clang-5 branch; I will try it there. In the meantime, I am adding a link to your comments above to the README. Thanks again.

[timmah]

With the Clang-6 branch, this seems to be building cleanly on Ubuntu, mainly using LLVM's cmake modules.