compilation failure with gcc5.x

[yonghong-song]

I hit a compilation error with the following error:

-bash-4.2$ make
[  1%] [FLEX][flex_lexer] Building scanner with flex 2.5.37
src/lexer.l:49: warning, rule cannot be matched
[  2%] [BISON][bison_parser] Building parser with bison 3.0.4
Scanning dependencies of target parser
[  3%] Building CXX object CMakeFiles/parser.dir/parser.tab.cc.o
c++: error: unrecognized command line option ‘-std=c++14’
make[2]: *** [CMakeFiles/parser.dir/parser.tab.cc.o] Error 1
make[1]: *** [CMakeFiles/parser.dir/all] Error 2
make: *** [all] Error 2
-bash-4.2$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/mnt/vol/engshare_nosnap/third-party2/gcc/5.x/centos7-native/c447969/bin/../libexec/gcc/x86_64-redhat-linux-gnu/5.5.0/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: /home/engshare/third-party2/gcc/5.x/src/gcc-5/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --prefix=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969 --exec-prefix=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969 --bindir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/bin --sbindir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/sbin --sysconfdir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/etc --datadir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/share --includedir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/include --libdir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/lib --libexecdir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/libexec --localstatedir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/var --sharedstatedir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/com --mandir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/share/man --infodir=/home/engshare/third-party2/gcc/5.x/centos7-native/c447969/share/info --with-gmp=/home/engshare/third-party2/gmp/6.0.0/centos7-native/da39a3e --with-mpfr=/home/engshare/third-party2/mpfr/3.1.2/centos7-native/1f53355 --with-mpc=/home/engshare/third-party2/mpc/1.0.2/centos7-native/6a50ac4 --with-isl=/home/engshare/third-party2/isl/0.18/centos7-native/1f53355 --with-pic --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran,lto --disable-libgcj --disable-gnu-unique-object --enable-linker-build-id --with-gnu-as --with-gnu-ld --disable-multilib --enable-libstdcxx-time --enable-gnu-indirect-function --enable-plugin
Thread model: posix
gcc version 5.x 20180625 (Facebook) 5.5.0+ (GCC) 
-bash-4.2$

maybe we should be relaxing -std=c++14 to allow old distro to use the tool?

[brendangregg]

I tried removing it in the root level CMakeLists.txt, and got a number of build errors:

In file included from /mnt/src/bpftrace-4/src/driver.h:6:0,
                 from src/parser.yy:32:
/mnt/src/bpftrace-4/build/parser.tab.hh: In instantiation of ‘void bpftrace::Parser::basic_symbol<Base>::clear() [with Base = bpftrace::Parser::by_type]’:
/mnt/src/bpftrace-4/build/parser.tab.cc:1224:25:   required from here
/mnt/src/bpftrace-4/build/parser.tab.hh:1363:9: error: no matching function for call to ‘bpftrace::variant<32ul>::destroy()’
         value.template destroy< ast::AttachPointList * > ();
         ^

environment is Ubuntu with a newer kernel:

# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) 

# uname -a
Linux bgregg-c5.9xl-i-xxx 4.18.0-rc6-virtual #1 SMP Wed Jul 25 00:51:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

# dpkg -l | grep llvm
ii  libllvm5.0:amd64                    1:5.0.2~svn328729-1~exp1~20180509124008.99 amd64        Modular compiler and toolchain technologies, runtime library
ii  llvm-5.0                            1:5.0.2~svn328729-1~exp1~20180509124008.99 amd64        Modular compiler and toolchain technologies
ii  llvm-5.0-dev                        1:5.0.2~svn328729-1~exp1~20180509124008.99 amd64        Modular compiler and toolchain technologies, libraries and headers
ii  llvm-5.0-runtime                    1:5.0.2~svn328729-1~exp1~20180509124008.99 amd64        Modular compiler and toolchain technologies, IR interpreter

[yonghong-song]

Correction for myself. The above -std=c++14 is not due to gcc 5.x. It is due to my setup whether cmake chooses an old version of gcc 4.8.5.

But even with correct 5.5.x gcc/g++ compiler, I still get the following compilation erros:

[ 15%] Building CXX object src/ast/CMakeFiles/ast.dir/ast.cpp.o
[ 16%] Building CXX object src/ast/CMakeFiles/ast.dir/codegen_llvm.cpp.o
In file included from /home/yhs/work/bpftrace/src/ast/codegen_llvm.cpp:1:
/home/yhs/work/bpftrace/src/bpforc.h:50:48: error: ‘ModuleHandleT’ in ‘class llvm::orc::IRCompileLayer<llvm::orc::RTDyldObjectLinkingLayer, 
llvm::orc::SimpleCompiler>’ does not name a type
   using ModuleHandle = decltype(CompileLayer)::ModuleHandleT;
                                                ^~~~~~~~~~~~~
/home/yhs/work/bpftrace/src/bpforc.h:65:3: error: ‘ModuleHandle’ does not name a type
   ModuleHandle addModule(std::unique_ptr<Module> M) {
   ^~~~~~~~~~~~
/home/yhs/work/bpftrace/src/bpforc.h: In constructor ‘bpftrace::BpfOrc::BpfOrc(llvm::TargetMachine*)’:
/home/yhs/work/bpftrace/src/bpforc.h:55:52: error: no matching function for call to ‘llvm::orc::RTDyldObjectLinkingLayer::RTDyldObjectLinkin
gLayer(bpftrace::BpfOrc::BpfOrc(llvm::TargetMachine*)::<lambda()>)’
       CompileLayer(ObjectLayer, SimpleCompiler(*TM))
                                                    ^
In file included from /home/yhs/work/bpftrace/src/bpforc.h:10,
                 from /home/yhs/work/bpftrace/src/ast/codegen_llvm.cpp:1:
/mnt/vol/engshare/third-party2/llvm-fb/stable/gcc-5-glibc-2.23/03859b5/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:240:3: no
te: candidate: ‘llvm::orc::RTDyldObjectLinkingLayer::RTDyldObjectLinkingLayer(llvm::orc::ExecutionSession&, llvm::orc::RTDyldObjectLinkingLa
yer::ResourcesGetter, llvm::orc::RTDyldObjectLinkingLayer::NotifyLoadedFtor, llvm::orc::RTDyldObjectLinkingLayer::NotifyFinalizedFtor)’
   RTDyldObjectLinkingLayer(
   ^~~~~~~~~~~~~~~~~~~~~~~~
/mnt/vol/engshare/third-party2/llvm-fb/stable/gcc-5-glibc-2.23/03859b5/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:240:3: no
te:   candidate expects 4 arguments, 1 provided
...

I am using latest llvm trunk (8.0), so I suspect this is due to the latest llvm issue.

It would be good if you can fix this issue since I am often running with latest llvm.

[brendangregg]

Yes, this sounds like llvm API changes. #149 shows the kind of work to fix this. What I don't know is how exactly: should we ifdef for the llvm versions, switch to the C API, or would an llvm engineer tell us there's a better way? (know any llvm engineers other than @4ast?)

I guess we could start by ifdef'ing the llvm versions.

[mmarchini]

Closing since this is covered by #137 and there's a proposed fix in #210, but feel free to reopen if there's anything left to be done here.