2

I want to add calls to the NVidia Monitoring Library to my CUDA application. However, the nvidia-ml library isn't part of CUDA; it's part of the device driver. Nevertheless, CUDA provides stubs for it. This appears to confuse CMake. I'm looking for a way to unconfuse CMake.

On the advice of my guru, I created a FindNvidiaML.cmake file

# set the base location
set(NVIDIA_ML_PATHS
  /usr/lib64
  /usr/lib64/nvidia
)

#  Look for the library
find_library( NVIDIA_ML_LIBRARY
              NAMES
                nvidia-ml
              HINTS
                ${NVIDIA_ML_PATHS}
)

#  Make sure valid
if( NVIDIA_ML_LIBRARY )
    SET( NVIDIA_ML_FOUND TRUE )
endif()

(NVIDIA_ML_LIBRARY has the value /usr/lib64/libnvidia-ml.so)

My main CMakeLists.txt file has this portion

  find_package(NvidiaML REQUIRED)

The specific product illustrated here CMakeLists.txt file looks like this:

set(myTarget DspTests)
add_executable( ${myTarget}
               Global_unittest.cpp

               nvSMI_unittest.cpp

               BlackmanHarris_unittest.cpp
               BlackmanHarrisCU_unittest.cu

               FFT_unittest.cu

               FindPeakKernel_unittest.cu

               )

target_include_directories( ${myTarget} SYSTEM PRIVATE
                            ${CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES}
)

set_target_properties( ${myTarget} PROPERTIES
                       CUDA_SEPARABLE_COMPILATION ON
                       POSITION_INDEPENDENT_CODE ON
)


target_link_libraries( ${myTarget}
                       dsp cufft ${NVIDIA_ML_LIBRARY}
                       gtest gtestApp
                )

add_gtest( ${myTarget} )

CMake output:

CMake Warning at dsp/unit/CMakeLists.txt:13 (add_executable):
  Cannot generate a safe linker search path for target DspTests because files
  in some directories may conflict with libraries in implicit directories:

    link library [libnvidia-ml.so] in /usr/lib64 may be hidden by files in:
      /usr/local/cuda/targets/x86_64-linux/lib/stubs

  Some of these libraries may not be found correctly.

Searching, I find

$ find /usr/ -name 'libnvidia-ml*' -ls 2>/dev/null
51097542 1512 -rwxr-xr-x   1 root     root      1545404 Jun 11  2019 /usr/lib/libnvidia-ml.so.418.67
51102213    0 lrwxrwxrwx   1 root     root           22 Jun 11  2019 /usr/lib/libnvidia-ml.so.1 -> libnvidia-ml.so.418.67
51102218    0 lrwxrwxrwx   1 root     root           17 Jun 11  2019 /usr/lib/libnvidia-ml.so -> libnvidia-ml.so.1
34907591 1536 -rwxr-xr-x   1 root     root      1569688 Apr  6  2019 /usr/lib64/libnvidia-ml.so.418.67
34907590    0 lrwxrwxrwx   1 root     root           22 Jun 11  2019 /usr/lib64/libnvidia-ml.so.1 -> libnvidia-ml.so.418.67
34972797    0 lrwxrwxrwx   1 root     root           22 Jun 11  2019 /usr/lib64/libnvidia-ml.so -> libnvidia-ml.so.418.67
17152088   32 -rwxr-xr-x   1 root     root        31808 Apr 24  2019 /usr/local/cuda-10.1/targets/x86_64-linux/lib/stubs/libnvidia-ml.so

This is not a duplicate of CMake cannot generate a safe linker search path - yocto 2.4 or CMake Warning: Cannot generate a safe linker search path for target although the symptoms are similar. It is possibly a duplicate of CMAKE - runtime library hidden files

Despite the warning, the code does link properly to the library in /usr/lib64, and it does run. So there is no error condition here. However, such a verbose warning in the output certainly gives the illusion of an error. Given the installation path of the NVidia driver, and the search paths required for CUDA building, and the actual duplicate libraries, the condition seems unavoidable.

The question is, how can I silence this warning?

Environment:

CentOS 7.3 gcc 7.3 CUDA 10.1 CMake 3.13.5

jwm
  • 1,504
  • 1
  • 14
  • 29
  • You *always* should link against the stub versions of libraries in the toolkit, not the live versions in the filesystem – talonmies May 29 '20 at 06:12
  • I was wondering about the stubs. Can you elaborate? – jwm May 29 '20 at 07:44
  • The stubs are there so you can build on systems without a GPU and build driver version agnostic applications. If you link against your driver version of a library, then that is the dependency which will be built into the executable. If you use the stub, it won't. nvml is not unique in this respect. The whole driver API is the same and I would suggest using the same logic for the nvml that is probably already built into CMake. I don't use it so I can't help you further on how to do that – talonmies May 29 '20 at 08:01

1 Answers1

1

The solution is to remove my FindNvidaML.cmake file. Turns out my guru's knowledge is dated and the intrisic support for CUDA in CMake, coupled with the stubs in CUDA 10.1 make this approach obsolete.

As the answers to other similar questions point out, the warning is describing the case where the code was linked against one library (in this case, explicitly /usr/lib64/libnvidia-ml.so) but at runtime may want to deduce a different library (found in /usr/local/cuda/targets/x86_64-linux/lib/stubs)

Changing the target CMakeList.txt file to be more generic results in a successful build and no warning:

target_link_libraries( ${myTarget}
                       dsp cufft nvidia-ml
                       gtest gtestApp
                )
talonmies
  • 70,661
  • 34
  • 192
  • 269
jwm
  • 1,504
  • 1
  • 14
  • 29