bpf: use MCJIT explicitly for ExecutionEngine

When BPFModule finalized the module, it set UseOrcMCJITReplacement to
true to use OrcJIT for ExecutionEngine. However, this never worked.
First, in clang_libs.cmake, mcjit is in the library list instead of
orcjit, so ExecutionEngine always fell back to MCJIT.
Second, even if OrcJIT was linked correctly, it actually broke bcc.
For OrcJIT, finalizeObject() is just an empty function. The code
generation is delayed till getPointerToFunction() or runFunction(), so
the current implementation of BPFModule won't work for OrcJIT.

This bug was covered when using the separate LLVM share libraries. If
the system builds LLVM into an unified share library, then OrcJIT will
be used and bcc would fail to generate BPF bytecodes without any
warning.
Signed-off-by: Gary Lin <glin@suse.com>

src/cc/bpf_module.cc

@@ -455,7 +455,7 @@ unique_ptr<ExecutionEngine> BPFModule::finalize_rw(unique_ptr<Module> m) {
   string err;
   EngineBuilder builder(move(m));
   builder.setErrorStr(&err);
-  builder.setUseOrcMCJITReplacement(true);
+  builder.setUseOrcMCJITReplacement(false);
   auto engine = unique_ptr<ExecutionEngine>(builder.create());
   if (!engine)
     fprintf(stderr, "Could not create ExecutionEngine: %s\n", err.c_str());
@@ -596,7 +596,7 @@ int BPFModule::finalize() {
   builder.setErrorStr(&err);
   builder.setMCJITMemoryManager(ebpf::make_unique<MyMemoryManager>(&sections_));
   builder.setMArch("bpf");
-  builder.setUseOrcMCJITReplacement(true);
+  builder.setUseOrcMCJITReplacement(false);
   engine_ = unique_ptr<ExecutionEngine>(builder.create());
   if (!engine_) {
     fprintf(stderr, "Could not create ExecutionEngine: %s\n", err.c_str());