Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[BUILD] Fix LLVM libraries cmake symbol #1461
Original issue discussion:
Thanks for contributing to TVM! Please refer to guideline https://docs.tvm.ai/contribute/ for useful information and tips. After the pull request is submitted, please request code reviews from others in the community.
OK, I understand the concerns. On our machine LLVM_LIBS contains a long list of static library entries followed by a dynamic library entry, like this:
The initial error was caused by a singleton, which was executed twice: first time by a static part of llvm, coming from libtvm.so, second time by dynamic library. Note, that systems which don't distribute dynamic version of LLVM are not affected. Jenkins seems to be lucky in this sence.
For the affected systems, the problem may be solved by either 1) linking with only static llvm or 2) linking with only dynamic llvm. Initially we suggested the first approach, the latest patch implements the second one which also works.
Number 2 is also less invasive, since it changes only one line of code. From the other hand, this way we wouldn't be able to use libtvm.so with libLLVM.so in applications, since both libraries would try to execute singleton and the second attempt will fail.
(in our case, -lLLVM was added only to demonstrate the issue, it is not actually required)
The latest patch prefers dynamic LLVM if it is available and defaults to static linkage otherwise. According to 'Build LLVM with CMake' guide, dynamic library contains all the components, so the basic presence check should be enough.
Just discovered, that Jenkins uses explicitly-defined llvm-config, like