CODEWITHSUNDEEP
llvmbazel
gruszczy
gruszczy

Reputation: 42208

llvm: dyld: Symbol not found: __ZN4llvm11RuntimeDyld13MemoryManager6anchorEv

I am playing with LLVM and I hit an issue when trying to use JIT. I was able to build a compiler, it can be compiled, linked and it runs correctly (it compiles my toy programs). However, when I am trying to use build a JIT, it fails.

dyld: Symbol not found: __ZN4llvm11RuntimeDyld13MemoryManager6anchorEv
  Referenced from: /Users/gruszczy/Projects/shwifty/./bazel-bin/_solib_darwin//liblibjit.so
  Expected in: flat namespace
 in /Users/gruszczy/Projects/shwifty/./bazel-bin/_solib_darwin//liblibjit.so
Abort trap: 6

I use Bazel to build everything, these are my build rules:

new_local_repository(
    name = "llvm",
    path = "/opt/local/libexec/llvm-4.0",
    build_file= "llvm.BUILD")

cc_library(
    name = "main",
    srcs = glob(["lib/*.a"]),
    hdrs = glob(["include/**/*.*"]),
    visibility = ["//visibility:public"],
    copts = ["-Iexternal/llvm/include"],
)

I use JIT in tests (I generate IR in the test then jit it, then run the method to see if it worked).

cc_library(
    name = "jit",
    srcs = ["jit.cc"],
    hdrs = ["jit.h"],
    deps = [
        ":ast",
        ":common",
        "@llvm//:main"
    ],
    copts = GENERAL_COPTS)

cc_test(
    name = "codegen_test",
    srcs = ["codegen_test.cc"],
    deps = [
        ":ast",
        ":jit",
        ":lexer",
        ":parser",
        ":codegen",
        "@gtest//:main",
        "@llvm//:main"
    ],
    copts = TEST_COPTS,
    data = [":examples"],
    size = "small"
)

Any suggestions what I might be missing?

Upvotes: 3

Views: 1393

Answers (1)

hlopko
hlopko

Reputation: 3268

The source of confusion is that Bazel by default links binaries statically, but tests dynamically. This makes the test-code-refactor loop faster, because changes to the test code only trigger the rebuild of the test, not the whole application. It can be disabled by setting linkstatic = 1 on codegen_test target.

As to why the symbols are not present in codegen_test when built as a shared library, that's much harder question and would need more project-specific information. But a possible solution might be to mark targets producing VMRuntimeDyld.a and VMMCJit.a as alwayslink = 1.

For the completeness, here's the link to an issue you reported on bazel.

Upvotes: 4

Related Questions