bcc install failing on archlinux

[paipanka]

Hi,

As suggested in the install instructions, I am using yaourt to install the bcc related packages on my arch linux system. I started with the command - yaourt -S bcc but it fails with the following errors. Could you please suggest the next steps to rectify this.

usr/include/llvm/IR/Instructions.h:70:12: note:   no known conversion for argument 2 from ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ to ‘unsigned int’
/tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/b/codegen_llvm.cc: In member function ‘virtual ebpf::StatusTuple ebpf::cc::CodegenLLVM::visit_func_decl_stmt_node(ebpf::cc::FuncDeclStmtNode*)’:
/tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/b/codegen_llvm.cc:1175:67: error: invalid conversion from ‘const char*’ to ‘unsigned int’ [-fpermissive]
   retval_ = new AllocaInst(fn->getReturnType(), "ret", label_entry);
                                                                   ^
In file included from /tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/b/codegen_llvm.cc:29:0:
/usr/include/llvm/IR/Instructions.h:70:12: note:   initializing argument 2 of ‘llvm::AllocaInst::AllocaInst(llvm::Type*, unsigned int, llvm::Value*, const llvm::Twine&, llvm::Instruction*)’
   explicit AllocaInst(Type *Ty, unsigned AddrSpace,
            ^~~~~~~~~~
/tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/b/codegen_llvm.cc:1177:62: error: invalid conversion from ‘const char*’ to ‘unsigned int’ [-fpermissive]
   errval_ = new AllocaInst(B.getInt64Ty(), "err", label_entry);

/tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/clang/loader.cc: In member function ‘int ebpf::ClangLoader::parse(std::unique_ptr<llvm::Module>*, std::unique_ptr<std::vector<ebpf::TableDesc> >*, const string&, bool, const char**, int)’:
/tmp/yaourt-tmp-pankaj/aur-bcc/src/bcc-0.3.0/src/cc/frontends/clang/loader.cc:231:38: error: ‘IK_C’ was not declared in this scope
         FrontendInputFile(main_path, IK_C));
                                      ^~~~

[drzaeus77]

The build instructions seem to be referencing bcc 0.3.0, which is quite an old release. The PKGBUILD should be updated to at least 0.4.0 or master to fix this error.

[cippaciong]

I have been using bcc 0.4.0 compiled from a modified PKGBUILD for a couple of weeks and it builds and runs flawlessly.
This PKGBUILD should work for you

pkgbase=bcc
pkgname=('bcc' 'bcc-tools' 'python-bcc' 'python2-bcc')
pkgver=0.4.0
pkgrel=1
pkgdesc="BPF Compiler Collection"
arch=('x86_64')
url="https://github.com/iovisor/bcc"
license=('Apache')
conflicts=('bcc-git')
makedepends=('cmake' 'clang>=3.7.0' 'llvm>=3.7.0' 'flex' 'bison' 'python'
             'python2')
source=("https://github.com/iovisor/${pkgname}/archive/v${pkgver}.tar.gz")
sha256sums=('f77dd07262e8365e48589bf0475e3248e4e77deae0f90e4fb77af26255bce87d')

build() {
  # make sure repetitive builds are clean
  [[ -d "${srcdir}/${pkgbase}-${pkgver}/build" ]] && \
    rm -rf "${srcdir}/${pkgbase}-${pkgver}/build"
  mkdir "${srcdir}/${pkgbase}-${pkgver}/build"
  cd "${srcdir}/${pkgbase}-${pkgver}/build"

  # we don't care which python here for the core C library
  cmake .. -DREVISION=${pkgver} \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib
  make
}

package_bcc() {
  pkgdesc="BPF Compiler Collection  - C library and examples"
  makedepends=('cmake' 'clang>=3.7.0' 'llvm>=3.7.0' 'flex' 'bison')
  provides=('bcc' 'libbcc')
  conflicts=('bcc-git')
  depends=('linux-headers')
  optdepends=('bcc-tools: Python utilites using the BCC library'
              'python-bcc: Python 3 bindings for BCC'
              'python2-bcc: Python 2 bindings for BCC')

  # this installs the kitchen sink
  cd "${srcdir}/${pkgbase}-${pkgver}/build"
  make DESTDIR="${pkgdir}/" install

  # these go in a split package python*-bcc
  rm -rf "${pkgdir}"/usr/lib/python*

  # these go in a split package bcc-tools
  rm -rf "${pkgdir}"/usr/share/bcc/{tools,man}
}

package_bcc-tools() {
  pkgdesc="BPF Compiler Collection - Tools"
  depends=('bcc')
  conflicts=('bcc-tools-git')
  optdepends=('python-bcc: Python 3 bindings for BCC'
              'python2-bcc: Python 2 bindings for BCC')

  cd "${srcdir}/${pkgbase}-${pkgver}/build/tools"
  make DESTDIR="${pkgdir}/" install

  cd "${srcdir}/${pkgbase}-${pkgver}/build/man"
  make DESTDIR="${pkgdir}/" install

}

package_python-bcc() {
  pkgdesc="BPF Compiler Collection - Python 3 bindings"
  makedepends=('cmake')
  depends=('bcc' 'python')
  conflicts=('python-bcc-git')

  # the C lib s already built, force a quick python3 binding build
  cd "${srcdir}/${pkgbase}-${pkgver}/build"
  cmake .. -DREVISION=${pkgver} -DPYTHON_CMD="python" \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib
  make

  # now install just those bindings
  cd "${srcdir}/${pkgbase}-${pkgver}/build/src/python"
  make DESTDIR="${pkgdir}/" install
}

package_python2-bcc() {
  pkgdesc="BPF Compiler Collection - Python 2 bindings"
  makedepends=('cmake')
  depends=('bcc' 'python2')
  conflicts=('python2-bcc-git')

  # the C lib s already built, force a quick python2 binding build
  cd "${srcdir}/${pkgbase}-${pkgver}/build"
  cmake .. -DREVISION=${pkgver} -DPYTHON_CMD="python2" \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=/usr/lib
  make

  # now install just those bindings
  cd "${srcdir}/${pkgbase}-${pkgver}/build/src/python"
  make DESTDIR="${pkgdir}/" install
}

[goldshtn]

@paipanka Can you please circle back and see if this resolves your issue?

[SanchayanMaity]

@cippaciong Thanks. Your pkgbuild seems to work perfectly fine.

[tonylambiris]

Here is a PKGBUILD for 0.5.0, includes this PR for fixing LLVM build issue.

Note: in the PKGBUILD you'll have to grab this patch and name it to fix_build_issue_for_llvm_5.0.1.patch

[Edenhofer]

I recently adopted the package and will try to maintain it in the future as good as possible. Basically I overhauled the entire PKGBUILD and it builds just fine now.
Please feel free to let me know of any further criticism or request concerning the package (preferably via the AUR).

IMHO this issue can be considered closed.