[PR #627] [MERGED] fix(setup): resolve real NVSHMEM/NCCL SO names for pip-wheel installs #671

New issue

Closed

opened 2026-10-27 21:05:08 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-27 21:05:08 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/DeepEP/pull/627
Author: @MayDomine
Created: 5/9/2026
Status: ✅ Merged
Merged: 5/22/2026
Merged by: @sphish

Base: main ← Head: fix/link-pip-wheel-soname

📝 Commits (1)

ce78b03 fix(setup): resolve real NVSHMEM/NCCL SO names for pip-wheel installs

📊 Changes

1 file changed (+36 additions, -9 deletions)

View changed files

📝 setup.py (+36 -9)

📄 Description

Summary

Fix cannot find -l:libnvshmem_host.so (and the analogous NCCL failure) when DeepEP is built against the official NVIDIA pip wheels (nvidia-nvshmem-cu12, nvidia-nccl-cu12).

Problem

The pip wheels only ship the SONAME-suffixed libraries:

libnvshmem_host.so.3
libnccl.so.2

…and omit the unversioned symlinks (libnvshmem_host.so, libnccl.so) that a system tarball install would create.

setup.py currently passes -l:libnvshmem_host.so and -l:libnccl.so to the linker. Because -l:NAME is an exact-name match, ld refuses to consider libnvshmem_host.so.3 and the build fails with:

/usr/bin/ld: cannot find -l:libnvshmem_host.so: No such file or directory
collect2: error: ld returned 1 exit status
error: command '/usr/bin/x86_64-linux-gnu-g++' failed with exit code 1

Interestingly, get_nvshmem_host_lib_name() already exists in setup.py for exactly this reason — but it's never wired into extra_link_args, so the hard-coded string still wins. NCCL has the same hard-coded string and the same wheel-vs-tarball mismatch, just no helper to back it up.

Fix

Generalise the existing helper into _find_versioned_so(base_dir, prefix) that prefers the unversioned symlink when present (tarball install) and falls back to the SONAME file (pip-wheel install).
Add get_nccl_lib_name() mirroring get_nvshmem_host_lib_name().
Use both helpers when assembling extra_link_args so -l:NAME carries the real on-disk filename.

Test plan

Validated in a container that has only the pip-wheel installs (nvidia-nvshmem-cu12==3.6.5, nvidia-nccl-cu13==2.30.4) and no system tarball NVSHMEM/NCCL:

Before: build fails at link with cannot find -l:libnvshmem_host.so.
After:
- python setup.py bdist_wheel finishes successfully.
- ldd deep_ep/_C*.so resolves both libraries to the wheel-shipped SONAME files:
```
libnvshmem_host.so.3 => .../nvidia/nvshmem/lib/libnvshmem_host.so.3
libnccl.so.2          => .../nvidia/nccl/lib/libnccl.so.2
```

Compatibility

No behaviour change for tarball installs. The helper checks for the unversioned symlink first and uses it when present, so existing setups that rely on libnvshmem_host.so / libnccl.so continue to pick those up.

_{🔄 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/627 **Author:** [@MayDomine](https://github.com/MayDomine) **Created:** 5/9/2026 **Status:** ✅ Merged **Merged:** 5/22/2026 **Merged by:** [@sphish](https://github.com/sphish) **Base:** `main` ← **Head:** `fix/link-pip-wheel-soname` --- ### 📝 Commits (1) - [`ce78b03`](https://github.com/deepseek-ai/DeepEP/commit/ce78b03cdf5193aedf8dddb831bdffd7b741b9f5) fix(setup): resolve real NVSHMEM/NCCL SO names for pip-wheel installs ### 📊 Changes **1 file changed** (+36 additions, -9 deletions) <details> <summary>View changed files</summary> 📝 `setup.py` (+36 -9) </details> ### 📄 Description ## Summary Fix `cannot find -l:libnvshmem_host.so` (and the analogous NCCL failure) when DeepEP is built against the official NVIDIA pip wheels (`nvidia-nvshmem-cu12`, `nvidia-nccl-cu12`). ## Problem The pip wheels only ship the SONAME-suffixed libraries: - `libnvshmem_host.so.3` - `libnccl.so.2` …and **omit the unversioned symlinks** (`libnvshmem_host.so`, `libnccl.so`) that a system tarball install would create. `setup.py` currently passes `-l:libnvshmem_host.so` and `-l:libnccl.so` to the linker. Because `-l:NAME` is an *exact-name* match, ld refuses to consider `libnvshmem_host.so.3` and the build fails with: ``` /usr/bin/ld: cannot find -l:libnvshmem_host.so: No such file or directory collect2: error: ld returned 1 exit status error: command '/usr/bin/x86_64-linux-gnu-g++' failed with exit code 1 ``` Interestingly, `get_nvshmem_host_lib_name()` already exists in `setup.py` for exactly this reason — but it's never wired into `extra_link_args`, so the hard-coded string still wins. NCCL has the same hard-coded string and the same wheel-vs-tarball mismatch, just no helper to back it up. ## Fix - Generalise the existing helper into `_find_versioned_so(base_dir, prefix)` that prefers the unversioned symlink when present (tarball install) and falls back to the SONAME file (pip-wheel install). - Add `get_nccl_lib_name()` mirroring `get_nvshmem_host_lib_name()`. - Use both helpers when assembling `extra_link_args` so `-l:NAME` carries the real on-disk filename. ## Test plan Validated in a container that has only the pip-wheel installs (`nvidia-nvshmem-cu12==3.6.5`, `nvidia-nccl-cu13==2.30.4`) and no system tarball NVSHMEM/NCCL: - Before: build fails at link with `cannot find -l:libnvshmem_host.so`. - After: - `python setup.py bdist_wheel` finishes successfully. - `ldd deep_ep/_C*.so` resolves both libraries to the wheel-shipped SONAME files: ``` libnvshmem_host.so.3 => .../nvidia/nvshmem/lib/libnvshmem_host.so.3 libnccl.so.2 => .../nvidia/nccl/lib/libnccl.so.2 ``` ## Compatibility No behaviour change for tarball installs. The helper checks for the unversioned symlink first and uses it when present, so existing setups that rely on `libnvshmem_host.so` / `libnccl.so` continue to pick those up. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-27 21:05:08 +00:00