CUDA共享库编译正常但链接/ptxas报错求助

Hey there, let’s dig into your CUDA shared library linking/ptxas error issue. I’ve tackled similar problems plenty of times, so let’s walk through the most likely culprits and fixes tailored to your minimal reproduction setup.

Just because the library compiled without errors doesn’t mean it’s properly set up for CUDA. Here’s what to verify:

• Use nvcc, not just g++/clang: If your FileA.cpp or TempClass.h touches any CUDA runtime functions (even indirectly, like wrapping memset with CUDA-aware logic), compiling with a regular C++ compiler will miss critical CUDA symbol handling. A correct library build command looks like this:

  nvcc -shared -fPIC -o libmycuda.so FileA.cpp -lcudart
  

  The -fPIC flag is mandatory for shared libraries, -lcudart links the CUDA runtime, and using nvcc ensures CUDA-specific code is processed correctly.
• Inspect exported symbols: Run nm -D libmycuda.so | grep your_function_name (replace with your memset replacement function) to check if the symbol is properly exported. If you see U next to the symbol, that means it’s undefined—your library didn’t link the CUDA runtime correctly, or the function wasn’t implemented properly.

Most errors pop up here because the main program isn’t properly aligned with the library’s CUDA setup:

• Match GPU architecture flags: PTXAS errors almost always stem from mismatched GPU compute architectures between the library and main program. If you compiled the library with a default architecture but the main program targets a specific sm_xx version, they’ll clash. Unify the architecture for both builds:

  # Build library with explicit architecture
  nvcc -shared -fPIC -arch=sm_75 -o libmycuda.so FileA.cpp -lcudart
  # Build main program with the same architecture
  nvcc -arch=sm_75 -o main main.cpp -L./ -lmycuda -lcudart
  

  Replace sm_75 with your GPU’s compute capability (check via nvidia-smi or CUDA docs).
• Link correctly: Don’t forget to specify the library path (-L./ if it’s in the current directory) and library name (-lmycuda), plus re-link the CUDA runtime (-lcudart) even if the library already uses it—this avoids missing runtime symbols during main program linking.

Since you’re replacing a C function like memset, symbol mangling is a common gotcha:

• Wrap exported functions in extern "C": C++ compilers mangle function names, which means a C-style call in main.cpp won’t find your library’s symbols. Update FileA.h to enforce C-style symbol exports:

  // FileA.h
  #ifdef __cplusplus
  extern "C" {
  #endif
  
  // Your memset replacement function
  void my_memset(void* ptr, int value, size_t num);
  
  #ifdef __cplusplus
  }
  #endif
  

• Ensure header consistency: If TempClass.h is included in both the library and main program, make sure there are no conflicting macro definitions or struct layouts—these can break ABI compatibility and cause obscure linking errors.

If compilation succeeds but you get a "shared library not found" error at runtime:

• Either set the library path temporarily when running the program:

  LD_LIBRARY_PATH=./ ./main
  

• Or embed the path directly into the executable during compilation (so you don’t have to set the env var every time):

  nvcc -arch=sm_75 -o main main.cpp -L./ -lmycuda -lcudart -Wl,-rpath=./
  

内容的提问来源于stack exchange，提问作者Tim