Unable to build LLDB 4.0 on Debian Linux

Subprojects LLDB
#1

Hi,

I am having a problem building the 4.0 release branch of LLDB on Debian Stretch. Cmake returns the following fault:

– LLDB version: 4.0.0
– Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version “2.9.4”)
– Performing Test HAVE_PROCESS_VM_READV
– Performing Test HAVE_PROCESS_VM_READV - Success
– Found Curses: /usr/lib/x86_64-linux-gnu/libcurses.so
– Looking for GLIBCXX
– Looking for GLIBCXX - found
– Performing Test LLDB_USING_LIBSTDCXX_4_9
– Performing Test LLDB_USING_LIBSTDCXX_4_9 - Success
– Looking for backtrace
– Looking for backtrace - not found
– Could NOT find Backtrace (missing: Backtrace_LIBRARY)
– Found Doxygen: /usr/bin/doxygen (found version “1.8.13”)
– Found SWIG: /usr/bin/swig3.0 (found version “3.0.10”)
– Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED
– Performing Test CXX_SUPPORTS_NO_MACRO_REDEFINED - Success
– Symbols (liblldb): exporting all symbols from the lldb namespace
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Backtrace_LIBRARY (ADVANCED)
linked by target “liblldb” in directory clang-4.0/tools/lldb/source/API
linked by target “LLDBBreakpointTests” in directory clang-4.0/tools/lldb/unittests/Breakpoint
linked by target “LLDBCoreTests” in directory clang-4.0/tools/lldb/unittests/Core
linked by target “EditlineTests” in directory clang-4.0/tools/lldb/unittests/Editline
linked by target “ExpressionTests” in directory clang-4.0/tools/lldb/unittests/Expression
linked by target “HostTests” in directory clang-4.0/tools/lldb/unittests/Host
linked by target “InterpreterTests” in directory clang-4.0/tools/lldb/unittests/Interpreter
linked by target “LanguageCPlusPlusTests” in directory clang-4.0/tools/lldb/unittests/Language/CPlusPlus
linked by target “LLDBPlatformTests” in directory clang-4.0/tools/lldb/unittests/Platform
linked by target “ProcessGdbRemoteTests” in directory clang-4.0/tools/lldb/unittests/Process/gdb-remote
linked by target “LLDBMinidumpTests” in directory clang-4.0/tools/lldb/unittests/Process/minidump
linked by target “ScriptInterpreterPythonTests” in directory clang-4.0/tools/lldb/unittests/ScriptInterpreter/Python
linked by target “SymbolTests” in directory clang-4.0/tools/lldb/unittests/Symbol
linked by target “SymbolFileDWARFTests” in directory clang-4.0/tools/lldb/unittests/SymbolFile/DWARF
linked by target “UnwindAssemblyx86Tests” in directory clang-4.0/tools/lldb/unittests/UnwindAssembly/x86
linked by target “UtilityTests” in directory clang-4.0/tools/lldb/unittests/Utility

– Configuring incomplete, errors occurred!
See also “build-4.0/bootstrap/CMakeFiles/CMakeOutput.log”.
See also “build-4.0/bootstrap/CMakeFiles/CMakeError.log”.

The output from CMakeError.log is:

Determining if the backtrace exist failed with the following output:
Change Dir: build-4.0/bootstrap/CMakeFiles/CMakeTmp

Run Build Command:“build-4.0/bin/ninja” “cmTC_1e735”
[1/2] Building C object CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
FAILED: CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o
/usr/bin/cc -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment -Werror -Werror=date-time -ffunction-sections -fdata-sections -o CMakeFiles/cmTC_1e735.dir/CheckSymbolExists.c.o -c build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c
build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ‘main’:
build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:11: error: ISO C forbids conversion of function pointer to object pointer type [-Werror=pedantic]
return ((int*)(&backtrace))[argc];
^
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.

File build-4.0/bootstrap/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <execinfo.h>

int main(int argc, char** argv)
{
(void)argv;
#ifndef backtrace
return ((int*)(&backtrace))[argc];
#else
(void)argc;
return 0;
#endif
}

It seems that the detection routine is invalid. The gcc in use is 6.3.0. Anyone any idea how to fix / work around this problem?

Many thanks,

Andy

#2

What's the cmake command you are using?

It sounds like you somehow ended up enabling -Werror, which is
confusing the backtrace-detection code (and probably most of the other
cmake compile checks).

One of the workarounds would be to disable -Werror.

pl

#3

This is in cmake detection code though, the options you set for your build have no bearing there right?

This looks like a bug in cmake to me, perhaps a newer cmake version can fix it?

#4

Sorry not to have come back sooner.

The problem is not the -Werror (I think) but the -pedantic that gets added during lldb configuration. Having looked through the cmake files, I cannot see how this is added though. Interestingly enough the backtrace detection is run earlier in configuration, possibly in the llvm part itself, where it passes without problem. The only difference in the log file is that earlier on there is no -pedantic option given.

Also, although this is an aside, if clang is the compiler, it also passes (with the -pedantic). Problem is, then I need to build clang to build clang :o)

Cheers,

Andy

#5

Technically, it's the combination of -Werror and -pedantic which is
causing the problem. Any single one of them would be fine :slight_smile:

I am not sure what could be the problem, LLDB's build files do not
explicitly add any of these flags, so they must be coming from
somewhere else. Without more information, it's hard to say from where.
If you send me your cmake command line, I can try to reproduce the
problem. Otherwise, you're pretty much on your own. All I can
recommend is to try the --trace cmake argument, which may give you an
idea where are those flags coming from.

pl

#6

Again, this has nothing to do with our build files, it is in cmakes internal builtin modules when it is trying to compile a program to see if a symbol exists. This looks like a cmake bug, try upgrading cmake

#7

If you set enough cmake variables, you can certainly force cmake to do
the build checks with -Werror. I am asking for the build command to
rule that out (among other things)