[lldb-dev] Unable to build LLDB 4.0 on Debian Linux
Pavel Labath via lldb-dev
lldb-dev at lists.llvm.org
Mon May 15 05:47:37 PDT 2017
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)
On 15 May 2017 at 11:57, Zachary Turner <zturner at google.com> wrote:
> 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
> On Mon, May 15, 2017 at 1:25 AM Pavel Labath <labath at google.com> wrote:
>>
>> Technically, it's the combination of -Werror and -pedantic which is
>> causing the problem. Any single one of them would be fine :)
>>
>> 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
>>
>> On 12 May 2017 at 19:21, Andy Gibbs <andyg1001 at hotmail.co.uk> wrote:
>> > 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
>> >
>> >
>> >
>> > ________________________________
>> > From: Zachary Turner <zturner at google.com>
>> > Sent: 02 May 2017 13:50
>> > To: Pavel Labath; Andy Gibbs
>> > Cc: lldb-dev at lists.llvm.org
>> > Subject: Re: [lldb-dev] Unable to build LLDB 4.0 on Debian Linux
>> >
>> > 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?
>> > On Tue, May 2, 2017 at 3:24 AM Pavel Labath via lldb-dev
>> > <lldb-dev at lists.llvm.org> wrote:
>> >>
>> >> 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
>> >>
>> >> On 28 April 2017 at 22:36, Andy Gibbs via lldb-dev
>> >> <lldb-dev at lists.llvm.org> wrote:
>> >> > 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
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > lldb-dev mailing list
>> >> > lldb-dev at lists.llvm.org
>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >> >
>> >> _______________________________________________
>> >> lldb-dev mailing list
>> >> lldb-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
More information about the lldb-dev
mailing list