Bug 578512 – sys-devel/llvm-3.7.1-r1[lldb] fails to build

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Adrian Bassett 2016-03-29 13:12:27 UTC]

Pace the comments in https://bugs.gentoo.org/show_bug.cgi?id=578392 I can add that llvm-3.7.1-r1[lldb] fails to build, stalling during the build of the lldb debugger itself:

FAILED: /usr/bin/clang++ -m32 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND -DLIBXML2_DEFINED -DLLDB_DISABLE_LIBEDIT -DLLDB_DISABLE_PYTHON -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/Breakpoint -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/source/Breakpoint -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/include -Itools/lldb/include -Iinclude -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/include -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/../clang/include -Itools/lldb/../clang/include -I/usr/include/libxml2 -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/source/. -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/source/Plugins/Process/Linux -I/var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/source/Plugins/Process/POSIX  -DNDEBUG -mstackrealign -fomit-frame-pointer -O2 -march=core2 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -pipe -Wno-error=unused  -D_GLIBCXX_USE_CXX11_ABI=0  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated-register  -fno-exceptions -fno-rtti -fPIC -fPIC -MMD -MT tools/lldb/source/Breakpoint/CMakeFiles/lldbBreakpoint.dir/BreakpointResolver.cpp.o -MF tools/lldb/source/Breakpoint/CMakeFiles/lldbBreakpoint.dir/BreakpointResolver.cpp.o.d -o tools/lldb/source/Breakpoint/CMakeFiles/lldbBreakpoint.dir/BreakpointResolver.cpp.o -c /var/tmp/portage/sys-devel/llvm-3.7.1-r1/work/llvm-3.7.1.src/tools/lldb/source/Breakpoint/BreakpointResolver.cpp
.
.
.
In file included from /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/shared_ptr_atomic.h:33:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/bits/atomic_base.h:312:16: error: cannot compile this atomic library call yet
      { return __atomic_add_fetch(&_M_i, __i, memory_order_seq_cst); }

Noting the comments in the above bug I also tried a modified ebuild where LLVM_LINK_LLVM_DYLIB (implying LLVM_BUILD_LLVM_DYLIB) replaced BUILD_SHARED_LIBS but without success.

Active gcc is 5.3.0 and llvm/clang are emerged as follows:

# [ebuild     U  ] sys-devel/llvm-3.7.1-r1:0/3.7.1::gentoo [3.7.1:0/3.7.1::gentoo] USE="clang gold libffi lldb ncurses static-analyzer xml -debug -doc -libedit -multitarget -ocaml -python {-test}" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7" VIDEO_CARDS="-radeon" 0 KiB

# [ebuild   R    ] sys-devel/clang-3.7.1-r100:0/3.7::gentoo  USE="static-analyzer -debug -multitarget -python" ABI_X86="32 (64) (-x32)" 0 KiB

What are the implications for other builds if I emerge llvm[-lldb]?  I mean, are the issues local to llvm itself or will they impact on other builds?

Masking llvm-3.7.1-r1 for now ...

[Comment 1 Holger Hoffstätte 2016-03-30 19:16:51 UTC]

(In reply to Adrian.Bassett from comment #0)

You say your active gcc is 5.3.0, but then quote the opposite (which is the reason for the problem):

> FAILED: /usr/bin/clang++ -m32 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND
          ^^^^^^^^^^^^^^^^
You are using clang (stale copy maybe?) to compile lldb as part of llvm, and that doesn't work because of unsupported headers. I got the same error when trying to build llvm with itself; it should work with 3.8.0 onwards.
Just make sure to use gcc and it will build.

[Comment 2 Adrian Bassett 2016-04-01 18:33:18 UTC]

(In reply to Holger Hoffstätte from comment #1)
> (In reply to Adrian.Bassett from comment #0)
> 
> You say your active gcc is 5.3.0, but then quote the opposite (which is the
> reason for the problem):
> 
> > FAILED: /usr/bin/clang++ -m32 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND
>           ^^^^^^^^^^^^^^^^
> You are using clang (stale copy maybe?) to compile lldb as part of llvm, and
> that doesn't work because of unsupported headers. I got the same error when
> trying to build llvm with itself; it should work with 3.8.0 onwards.
> Just make sure to use gcc and it will build.

Thanks for the comments.

You're quite right:  lldb does seem to need (gcc)/g++ to build it, but, using that compiler - 5.3.0, I now have llvm-3.7.1-r1 installed (ebuild modified to use LLVM_LINK_LLVM_DYLIB rather than the, for production builds, deprecated BUILD_SHARED_LIBS).

Previously I had been using llvm/clang to (re-)build itself but had only recently (at the time of the 3.7.1 -> 3.7.1-r1 upgrade) enabled the lldb flag to build the native debugger.

The problem now is that a revdep-rebuild of mesa[llvm] is required but won't build against 3.7.1-r1 claiming not to be able to find llvm shared libraries.
But that's another bug.

[Comment 3 Panagiotis Christopoulos (RETIRED) 2016-04-11 21:10:40 UTC]

Are you ok now?

[Comment 4 Michał Górny 2018-03-29 08:04:49 UTC]

This shouldn't happen with current dev-util/lldb.