针对你遇到的问题——程序未直接引用CUFFT却在运行时要求libcufft.so.9.0，以下是几个精准定位依赖来源的实用方法：

1. 逐层排查依赖库的动态链接需求 #

程序的依赖链是「程序 → 直接依赖库 → 间接依赖库」，ldd仅显示程序的直接依赖，所以需要逐层检查每个依赖库本身的依赖：

• 先列出程序的所有直接依赖：ldd your_program，记录所有输出的.so文件路径
• 对每个依赖库（比如PCL的libpcl_common.so、VTK的libvtkRenderingCore.so等）运行：

  readelf -d /path/to/library.so | grep NEEDED
  

  这个命令会输出该库明确声明需要的所有动态库，找到包含libcufft.so.9.0的那个库，它就是问题的源头。

2. 直接搜索库文件中的旧版本库名 #

如果readelf没找到（比如依赖是动态加载的），可以直接在库文件中搜索目标字符串：

strings /path/to/library.so | grep "libcufft.so.9.0"

只要某个库编译时链接了旧版本的CUFFT，这个字符串就会存放在库文件里，用这个方法能快速定位到对应的库。

3. 回溯PCL/VTK的编译配置 #

因为你是源码编译PCL和VTK并开启了CUDA支持，很可能是编译时环境中混入了CUDA 9.0的依赖：

• 找到PCL和VTK的编译目录，打开CMakeCache.txt，搜索CUDA_cufft_LIBRARY或CUDA_VERSION相关变量，确认是否指向了CUDA 9.0的路径
• 查看编译日志，检查CUDA相关组件（比如CUFFT）的版本是否和你当前使用的CUDA 10.0匹配

4. 检查交叉编译环境（若适用） #

你是在Ubuntu主机开发后部署到Jetson，若使用了交叉编译工具链：

• 确认交叉编译环境中的CUDA版本是否为10.0，是否不小心混入了CUDA 9.0的库文件
• 检查编译脚本中是否有硬编码的CUDA 9.0库路径

批量排查脚本（高效小技巧） #

如果依赖库太多逐个检查太麻烦，可以用脚本批量处理：

for lib in $(ldd your_program | awk '{print $3}' | grep -v '^$'); do
  if strings $lib | grep -q "libcufft.so.9.0"; then
    echo "Found dependency source: $lib"
  fi
done

这个脚本会自动遍历程序的所有直接依赖库，找出包含目标字符串的文件。

内容的提问来源于stack exchange，提问作者Diego Aguirre García