[Build] Show error message when using ROCm with LTO and different compilers

[davispuh]

Purpose

Currently when default compiler /usr/bin/c++ is GCC and when building with LTO (-flto=auto) when ROCm is using Clang then created shared libraries _C.abi3.so _moe_C.abi3.so, _rocm_C.abi3.so will be missing symbols like PyInit__C.

$ vllm serve
WARNING 02-24 16:24:26 [rocm.py:38] Failed to import from vllm._C with ImportError('dynamic module does not define module export function (PyInit__C)')
WARNING 02-24 16:24:26 [rocm.py:44] Failed to import from vllm._rocm_C with ImportError('dynamic module does not define module export function (PyInit__rocm_C)')
WARNING 02-24 16:24:30 [interface.py:225] Failed to import from vllm._C: ImportError('dynamic module does not define module export function (PyInit__C)')
[...]
(EngineCore_DP0 pid=306393) ERROR 02-24 16:24:50 [core.py:1006] AttributeError: '_OpNamespace' '_C' object has no attribute 'silu_and_mul'
[...]
(APIServer pid=306353) RuntimeError: Engine core initialization failed. See root cause above. Failed core proc(s): {}

$ c++ --version | head -n 1
c++ (GCC) 15.2.1 20260209
$ hipconfig --compiler
clang

The issue is that .o files contain GCC LTO IR which are ignored when linking with Clang.

Test Plan

1. Inspect symbols for _C.abi3.so _moe_C.abi3.so, _rocm_C.abi3.so
2. Ensure Python imports work

Test Result

Without this PR:

$ nm -D _C.abi3.so | grep PyInit__C
nm: _C.abi3.so: plugin needed to handle lto object
$ nm -D _rocm_C.abi3.so | grep PyInit__rocm_C
nm: _rocm_C.abi3.so: plugin needed to handle lto object
$ nm -D _moe_C.abi3.so | grep PyInit__moe_C
nm: _moe_C.abi3.so: plugin needed to handle lto object
$ python -c 'import vllm._C'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import vllm._C
ImportError: dynamic module does not define module export function (PyInit__C)

With this PR:

$ nm -D _C.abi3.so | grep PyInit__C
0000000028b615f0 T PyInit__C
$ nm -D _rocm_C.abi3.so | grep PyInit__rocm_C
0000000014020ad0 T PyInit__rocm_C
$ nm -D _moe_C.abi3.so | grep PyInit__moe_C
00000000023b1350 T PyInit__moe_C
$ python -c 'import vllm._C'

I also tried this:

diff --git a/cmake/utils.cmake b/cmake/utils.cmake
index bdb2ba74d..6f451fbb8 100644
--- a/cmake/utils.cmake
+++ b/cmake/utils.cmake
@@ -518,6 +518,7 @@ function (define_extension_target MOD_NAME)
     # Make sure we include the hipified versions of the headers, and avoid conflicts with the ones in the original source folder
     target_include_directories(${MOD_NAME} PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/csrc
       ${ARG_INCLUDE_DIRECTORIES})
+    set_target_properties(${MOD_NAME} PROPERTIES CMAKE_CXX_COMPILER ${HIP_CXX_COMPILER})
   else()
     target_include_directories(${MOD_NAME} PRIVATE csrc
       ${ARG_INCLUDE_DIRECTORIES})

But unfortunately it doesn't work, so can't set it only for these libraries 😞

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors.

You ask your reviewers to trigger select CI tests on top of fastcheck CI.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

[Copilot]

Pull request overview

Fixes ROCm/HIP builds with LTO when the default C++ compiler is GCC but HIP is using Clang, preventing missing PyInit_* symbols in generated Python extension shared libraries.

Changes:

• Detect LTO usage in HIP builds and attempt to align the C++ compiler with the HIP compiler.
• Set CMAKE_CXX_COMPILER to CMAKE_HIP_COMPILER when -flto is present.

Comments suppressed due to low confidence (1)

CMakeLists.txt:234

• The regex string escapes - as \\-, which is unnecessary in CMake regex here and reduces readability. Consider using MATCHES \"-flto\" (or checking CMAKE_INTERPROCEDURAL_OPTIMIZATION / IPO settings if that’s how LTO is controlled elsewhere) to make the condition clearer and less fragile.

  if (CMAKE_CXX_FLAGS MATCHES "\-flto")

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gemini-code-assist]

Code Review

This pull request addresses a critical build failure when using Link-Time Optimization (LTO) on ROCm with a mixed GCC and Clang toolchain. The proposed fix correctly identifies that the C++ compiler must match the HIP compiler (which provides the linker) for LTO to work. My review focuses on making this fix more robust from a build system perspective. While the current approach works, modifying global CMake variables like CMAKE_CXX_COMPILER mid-configuration can be risky. I've suggested an alternative that makes the requirement explicit by failing the build with a clear error message if the compilers don't match, which is a safer and more standard practice in CMake.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @davispuh.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[davispuh]

I rebased and updated PR so now it will show error message instead.

[Harry-Chen]

LGTM. Thanks!

[Harry-Chen]

@davispuh You need to properly sign-off your commit before we can proceed.

CC. @AndreasKaratzas PTAL

[davispuh]

@davispuh You need to properly sign-off your commit before we can proceed.

It is properly signed

Signed-off-by: Dāvis Mosāns <Dāvis@Atradu.AI>

but looks like your tool doesn't support SMTPUTF8

Commit sha: 1235d24, Author: Dāvis Mosāns, Committer: Dāvis Mosāns; Dāvis@Atradu.AI is not a valid email address.

GitHub's parser can't do it either lmao but that doesn't really matter.