fix(build): Link dl and pthread dependencies for tvm_ffi

[junrushao]

Should fix #344.

There are two linking issues:

• std::mutex is used in src/ffi/backtrace.cc, which means libtvm_ffi.so in theory should link with pthread.
• dlsym, dlopen, etc are used in src/ffi/extra/library_module_dynamic_lib.cc, which means it has to be linked with dl.

This PR adds those two dependencies.

[gemini-code-assist]

Summary of Changes

Hello @junrushao, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves critical linking issues within the tvm_ffi library by updating its CMake configuration. It ensures that the library correctly links against pthread for threading primitives and dl for dynamic library loading, thereby preventing potential build failures and ensuring proper runtime functionality for components that rely on these system features.

Highlights

• Pthread Dependency: Explicitly added the pthread dependency to the tvm_ffi targets (both shared and static libraries) to resolve linking issues related to std::mutex usage in src/ffi/backtrace.cc.
• Dynamic Library Dependency: Introduced conditional linking for dynamic library functions (dlsym, dlopen) by adding CMAKE_DL_LIBS to tvm_ffi targets. This addresses issues in src/ffi/extra/library_module_dynamic_lib.cc when TVM_FFI_USE_EXTRA_CXX_API is enabled.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly identifies and adds missing link dependencies for pthread and dl to the tvm_ffi library. The changes are well-justified by the use of std::mutex and dlopen/dlsym. My review includes suggestions to adjust the CMake linkage type for the static library variant (tvm_ffi_static) from PRIVATE to INTERFACE. This is a crucial change to ensure that link dependencies are correctly propagated to consumers of the static library, preventing linker errors in downstream projects.

[junrushao]

/gemini Review

[gemini-code-assist]

Code Review

This pull request correctly adds pthread and dl as dependencies for tvm_ffi to resolve linking issues. The use of std::mutex necessitates linking against pthread, and the use of dlopen/dlsym requires linking against dl. The changes in CMakeLists.txt correctly identify and link these dependencies. I have one suggestion to slightly refactor the CMake code for improved readability and maintainability by consolidating the target_link_libraries calls.

[junrushao]

/gemini Could you help check CMakeLists.txt for similar misuse of target_link_libraries?

[gemini-code-assist]

Thank you for the follow-up question, @junrushao. The target_link_libraries calls introduced in this pull request (lines 127, 128, 131, and 132) correctly address the linking issues for pthread and dl as described in the PR description.

However, my review is strictly limited to the changes presented in this pull request. Therefore, I cannot perform a comprehensive check of the entire CMakeLists.txt file for other potential misuses of target_link_libraries that are outside the scope of these specific modifications.

[tqchen]

linking dl makes sense. I am less sure about pthread since it is part of std, should it be handled by c++ std behavior?

[junrushao]

My understanding is that pthread becomes part of glibc since a certain version, but it’s not part of manylinux_2_28

[junrushao]

Below is from ChatGPT:

---

In practice, yes for Linux: if you use std::mutex you should expect your final link to include POSIX threads support.

What that means concretely depends on your toolchain:

• GCC/libstdc++ and Clang using libstdc++ (common case): you typically need to link with -pthread (preferred) or -lpthread (less complete).
• Modern glibc (“libpthread merged into libc” in glibc 2.34+): even if -lpthread doesn’t show up as a distinct DSO at runtime, you still generally want -pthread because it also sets compile-time and link-time flags (e.g., defines/requires thread-safe runtime behavior), not just a library.

Why you might not “see” it:

• If you run ldd and don’t see libpthread.so.0, that does not necessarily mean you aren’t using pthreads; on newer glibc the symbols may come from libc.so.6. The important part is that you built/linked with the proper thread flags.

Best practice

• Use -pthread, not -lpthread.

  • -pthread affects both compilation and linking.
  • -lpthread is only “link this library” and can be insufficient in some situations.

CMake

find_package(Threads REQUIRED)
target_link_libraries(your_target PRIVATE Threads::Threads)

So: std::mutex implies you are using the C++ threading library, which on Linux is implemented on top of pthreads; therefore you should link accordingly (typically via -pthread / Threads::Threads).