Building from source fails on Debian Stretch

[divergentdave]

I tried building bcc from source per the instructions in INSTALL.md, but I got the error below.

Performing C++ SOURCE FILE Test HAVE_REALLOCARRAY_SUPPORT failed with the following output:
Change Dir: /home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_8b4d0/fast"
make[2]: Entering directory '/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_8b4d0.dir/build.make CMakeFiles/cmTC_8b4d0.dir/build
make[3]: Entering directory '/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_8b4d0.dir/src.cxx.o
/usr/bin/c++     -g -O2 -fdebug-prefix-map=/home/david/Code/bpf/bcc=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_REALLOCARRAY_SUPPORT   -o CMakeFiles/cmTC_8b4d0.dir/src.cxx.o -c /home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx
/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:2:0: warning: "_GNU_SOURCE" redefined
 #define _GNU_SOURCE

<command-line>:0:0: note: this is the location of the previous definition
/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx: In function ‘int main()’:
/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:7:41: error: ‘reallocarray’ was not declared in this scope
         return !!reallocarray(NULL, 1, 1);
                                         ^
CMakeFiles/cmTC_8b4d0.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_8b4d0.dir/src.cxx.o' failed
make[3]: *** [CMakeFiles/cmTC_8b4d0.dir/src.cxx.o] Error 1
make[3]: Leaving directory '/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_8b4d0/fast' failed
make[2]: *** [cmTC_8b4d0/fast] Error 2
make[2]: Leaving directory '/home/david/Code/bpf/bcc/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'

Source file was:

#define _GNU_SOURCE
#include <stdlib.h>

int main(void)
{
        return !!reallocarray(NULL, 1, 1);
}

[yonghong-song]

This is triggered by src/cmake/FindCompilerFlag.cmake

# check whether reallocarray availability
# this is used to satisfy reallocarray usage under src/cc/libbpf/
CHECK_CXX_SOURCE_COMPILES(
"
#define _GNU_SOURCE
#include <stdlib.h>

int main(void)
{
        return !!reallocarray(NULL, 1, 1);
}
" HAVE_REALLOCARRAY_SUPPORT)

If the compilation failed, it should set HAVE_REALLOCARRAY_SUPPORT to FALSE and cmake should proceed. Could you help check why this is not the case?

[divergentdave]

I found that this was failing because the build scripts couldn't find the clang libraries.

Starting with a clean working directory, I deleted obj-x86_64-linux-gnu, and ran dh_auto_configure -- -DREVISION_LAST=0.9.0 -DREVISION=0.9.0 -DLLVM_DEFINITIONS="-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" -DPYTHON_CMD="python2;python3", which is the first step of the build process. This failed with the same reallocarray-related error.

I deleted obj-x86_64-linux-gnu again, made the following change, and ran the same dh_auto_configure command again. This time, the command completed successfully.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 94aac856..fc66b5d5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -40,7 +40,7 @@ find_package(LibElf REQUIRED)
 
 # clang is linked as a library, but the library path searching is
 # primitively supported, unlike libLLVM
-set(CLANG_SEARCH "/opt/local/llvm/lib;/usr/lib/llvm-3.7/lib;${LLVM_LIBRARY_DIRS}")
+set(CLANG_SEARCH "/opt/local/llvm/lib;/usr/lib/llvm-3.7/lib;/usr/lib/llvm-3.8/lib;/usr/lib/llvm-3.9/lib;${LLVM_LIBRARY_DIRS}")
 find_library(libclangAnalysis NAMES clangAnalysis HINTS ${CLANG_SEARCH})
 find_library(libclangAST NAMES clangAST HINTS ${CLANG_SEARCH})
 find_library(libclangBasic NAMES clangBasic HINTS ${CLANG_SEARCH})

On Debian stretch, clang-3.7 is not available for installation, but clang-3.8 and clang-3.9 are. Their library directories are as shown above. I don't know how execution order in cmake works, but it seems the change I made further down in CMakeLists.txt fixes the issue I ran into in cmake/FindCompilerFlag.cmake, which was included earlier.

The full build process, debuild -b -uc -us, gets further now, but hits a "No such file or directory" error when trying to include <clang/Basic/FileManager.h>. I suspect this means there's a problem with the clang include directories as well.

[divergentdave]

I fixed my problem with include directories. My system already had llvm-3.8-dev, libclang-3.9-dev, and llvm-3.9-dev installed, but not libclang-3.9-dev. cmake was picking up LLVM 3.9 when it was looking for LLVM, so when it looked in the LLVM include directory, the clang half of the header files weren't there. (INSTALL.md says to install the 3.8 packages) I installed libclang-3.9-dev, and now it gets through compilation and linking, though several tests fail.

Edit: For posterity, DEB_BUILD_OPTIONS=nocheck debuild -b -uc -us will build the package and skip running tests.

[ymartin59]

I am running "testing". Whereas I was able to build binaries with cmake/make, debuild -b -uc -us requires me to add following packages because of debian/control build-depends: clang-format-6.0 libclang-6.0-dev lvm-6.0-dev libedit-dev python-pyroute2 So it may be interesting to add alternative versions now in "testing": llvm-7-dev libclang-7-dev clang-format-7

[yonghong-song]

@ymartin59 could you submit a patch for this? Thanks!

[ymartin59]

Still on testing and discovered that Debian package is named bpfcc-tools probably because bcc was already used for a compiler. So it may not be useful to compile from GitHub source or even from Debian source package.

[dominusmi]

I had a similar problem of clang not being found. My problem was due to several llvm installations. Turns out that there some problems with aptitude version of LLVM versions >= 10 which I honestly do not understand, but for example see this and this so I'll leave my solution in case anyone needs it.

Running on

Ubuntu:
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.1 LTS
Release:	20.04
Codename:	focal

Kernel:
Linux 5.4.0-59-generic #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Commit:
b1ab869032611d9fcdaea56851cd6126cca2eba8

You can either build the whole llvm suite with versions >= 10 from source, or the simpler way out is to use the packages specified in INSTALL.md:

sudo apt install -y bison build-essential cmake flex git libedit-dev \
  libllvm7 llvm-7-dev libclang-7-dev python zlib1g-dev libelf-dev libfl-dev

Then, modify the CMakeLists.txt file at two points:

# force LLVM version 7 (line 54):
find_package(LLVM 7 REQUIRED CONFIG)

# force the specific clang for that LLVM (line 68):
set(CLANG_SEARCH "/usr/lib/llvm-7/lib;${LLVM_LIBRARY_DIRS}")
# note: your llvm lib may not be in '/usr/lib', that depends how your apt install is set

This solved the issue for me, hopefully other will find it useful.

[Azaretdodo]

By my side I have follow the install.md with llvm 14 without happen any errors on my Ubuntu

[HanFa]

From my side I am running Linux kali-linux-2021-1 5.10.0-kali4-arm64 #1 SMP Debian. The CMake error is gone after explicitly specifying the existed LLVM_ROOT.

e.g. rm -rf build && export LLVM_ROOT=/usr/lib/llvm-11