[PR #557] [CLOSED] Fix linking error with nvidia-nvshmem-cu12 3.5.19 #636

Closed
opened 2026-10-27 21:04:46 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/DeepEP/pull/557
Author: @windreamer
Created: 1/6/2026
Status: ❌ Closed

Base: main ← Head: fix_linking_nvshmem


📝 Commits (1)

  • 6e74c26 fix: fix link error with nvidia-nvshmem-cu12 3.5.19

📊 Changes

1 file changed (+2 additions, -0 deletions)

View changed files

📝 csrc/kernels/configs.cuh (+2 -0)

📄 Description

Motivation

After upgrading to NVSHMEM 3.5.19, we encountered a multiple definition linking error:

/usr/bin/ld: /home/windreamer/codebase/DeepEP/.venv/lib/python3.12/site-packages/nvidia/nvshmem/lib/libnvshmem_device.a(init_device.cu.o):(.bss+0x380): multiple definition of `nvshmemi_ibgda_device_state_d'; /home/windreamer/codebase/DeepEP/build/temp.linux-x86_64-cpython-312/csrc/deep_ep.o:/home/windreamer/codebase/DeepEP/.venv/lib/python3.12/site-packages/nvidia/nvshmem/include/device_host_transport/nvshmem_common_ibgda.h:351: first defined here

This happens because NVSHMEM 3.5.19 expects users to compile with -rdc=true (relocatable device code).

#if defined(__CUDACC_RDC__) || defined(__NVSHMEM_NUMBA_SUPPORT__)
#define EXTERN_CONSTANT extern __constant__
#elif defined(__clang__)
#define EXTERN_CONSTANT extern __constant__ __attribute__((address_space(4)))
#else
#define EXTERN_CONSTANT
#endif

github.com/NVIDIA/nvshmem@919760f413/src/include/device_host_transport/nvshmem_common_ibgda.h (L343-L349)

However, in DeepEP's build structure:

  1. deep_ep.cpp is compiled by the host compiler (g++), not nvcc. While DeepEP enables -rdc=true for .cu files, this flag is only recognized by nvcc and has no effect on host compilation.

  2. The header device_host_transport/nvshmem_common_ibgda.h contains a conditional definition of the global variable nvshmemi_ibgda_device_state_d. When included in deep_ep.cpp, the host compiler sees it as a definition rather than an extern declaration (since __CUDACC_RDC__ is not defined), causing the symbol to be incorrectly emitted in deep_ep.o. This conflicts with the canonical definition in libnvshmem_device.a.

Modification

The core issue is that device_host_transport/nvshmem_common_ibgda.h is a device-specific internal header that should never be included in host-compiled translation units. Instead of relying on -rdc=true (which doesn't affect host compilation), we restrict the inclusion of this header to only when nvcc is processing the file.

By guarding the inclusion with #ifdef __CUDACC__, we ensure that:

  • Device code (.cu files compiled by nvcc) can still access the necessary declarations
  • Host code (.cpp files compiled by g++) will never see this header or its problematic symbol definition

This prevents the duplicate symbol error while maintaining compatibility with NVSHMEM's device API usage in the kernel code.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/deepseek-ai/DeepEP/pull/557 **Author:** [@windreamer](https://github.com/windreamer) **Created:** 1/6/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix_linking_nvshmem` --- ### 📝 Commits (1) - [`6e74c26`](https://github.com/deepseek-ai/DeepEP/commit/6e74c2626e7c5222693e48ec1a704b862672d5bf) fix: fix link error with nvidia-nvshmem-cu12 3.5.19 ### 📊 Changes **1 file changed** (+2 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `csrc/kernels/configs.cuh` (+2 -0) </details> ### 📄 Description ## Motivation After upgrading to NVSHMEM 3.5.19, we encountered a multiple definition linking error: ``` /usr/bin/ld: /home/windreamer/codebase/DeepEP/.venv/lib/python3.12/site-packages/nvidia/nvshmem/lib/libnvshmem_device.a(init_device.cu.o):(.bss+0x380): multiple definition of `nvshmemi_ibgda_device_state_d'; /home/windreamer/codebase/DeepEP/build/temp.linux-x86_64-cpython-312/csrc/deep_ep.o:/home/windreamer/codebase/DeepEP/.venv/lib/python3.12/site-packages/nvidia/nvshmem/include/device_host_transport/nvshmem_common_ibgda.h:351: first defined here ``` This happens because NVSHMEM 3.5.19 expects users to compile with `-rdc=true` (relocatable device code). ```c++ #if defined(__CUDACC_RDC__) || defined(__NVSHMEM_NUMBA_SUPPORT__) #define EXTERN_CONSTANT extern __constant__ #elif defined(__clang__) #define EXTERN_CONSTANT extern __constant__ __attribute__((address_space(4))) #else #define EXTERN_CONSTANT #endif ``` https://github.com/NVIDIA/nvshmem/blob/919760f413fb834e76382d129ba9c3314ce722be/src/include/device_host_transport/nvshmem_common_ibgda.h#L343-L349 However, in DeepEP's build structure: 1. **`deep_ep.cpp` is compiled by the host compiler (g++)**, not nvcc. While DeepEP enables `-rdc=true` for `.cu` files, this flag is only recognized by nvcc and has no effect on host compilation. 2. The header `device_host_transport/nvshmem_common_ibgda.h` contains a conditional definition of the global variable `nvshmemi_ibgda_device_state_d`. When included in `deep_ep.cpp`, the host compiler sees it as a **definition** rather than an `extern` declaration (since `__CUDACC_RDC__` is not defined), causing the symbol to be incorrectly emitted in `deep_ep.o`. This conflicts with the canonical definition in `libnvshmem_device.a`. ## Modification The core issue is that `device_host_transport/nvshmem_common_ibgda.h` is a device-specific internal header that should never be included in host-compiled translation units. Instead of relying on `-rdc=true` (which doesn't affect host compilation), we restrict the inclusion of this header to only when **nvcc** is processing the file. By guarding the inclusion with `#ifdef __CUDACC__`, we ensure that: - Device code (`.cu` files compiled by nvcc) can still access the necessary declarations - Host code (`.cpp` files compiled by g++) will never see this header or its problematic symbol definition This prevents the duplicate symbol error while maintaining compatibility with NVSHMEM's device API usage in the kernel code. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-27 21:04:46 +00:00
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/DeepEP#636
No description provided.