Cannot-Find-File Error from Profiling Executable on Linux Server from Local Windows Using Nsight Compute

I have an executable, including CUDA kernels on a Linux server, and I would like to use the Nsight Compute on my local windows system to profile the remote executable in an interactive way. As I ran profiling, I got the following message:

Launching: /scratch/bbp_algo1/ziqi/SandBox/regera-gpu/Blazer/MercuryImageComputer/KT/leaf/M31/BrightField/bin/LeafStandalone/Release/12/LeafStandAlone.x86-64 (host: 10.70.72.71)
Process launched
Trying to connect to process…
Searching for attachable processes on 10.70.72.71:49152-49215…
/scratch/bbp_algo1/ziqi/SandBox/regera-gpu/Blazer/MercuryImageComputer/KT/leaf/M31/BrightField/bin/LeafStandalone/Release/12/LeafStandAlone.x86-64: error while loading shared libraries: libfftw3f.so.3: cannot open shared object file: No such file or directory

From my understanding, the profiling failed as a shared binary named “libfftw3f.so.3” cannot be found. This shared library was indeed linked to in our binary, but we had no problem running the executable on the remote server, and I am confused why in the case of Nsight Compute, it failed to find such a dynamic library, and failed profiling as a consequence. Can anyone point out how to fix the issue?

The likely reason is that some environment is different between your local shell when executing on the Linux target and your remote profiling session. You might have code that updates e.g. LD_LIBRARY_PATH or PATH environment variable in shell-specific init files (such as .bashrc) that does not get executed during remote profiling. You can set such environment variables in the Nsight Compute connection dialog when configuring the remote profiling session.

If you need to debug this further, consider e.g. writing the environment to a file from a small shell script that you launch using remote profiling.

I see. Actually, there is a field named “environment” where environment variables need to be set. I set the variable named “LD_LIBRARY_PATH” and then remote profiling worked fine. So it seems that this profiler does not start from a Linux shell, as otherwise, environment variables should have been automatically loaded.

Thanks for support!