需要检查 EDA 工具在自身和操作系统（Linux）中的依赖性的最佳做法

将 EDA 工具套件发布到生产计算环境 (RHEL) 中可能会出现问题，尤其是在其发布或操作系统级别中缺少某些共享对象的情况下。

迁移操作系统也会带来同样的问题，因为 glibc 版本可能会更改，其他系统级别的 .so 文件也可能会丢失。

EDA 工具套件（例如 Synopsys VCS）可能会有数十个甚至数百个用户可执行文件，这些可执行文件通常是具有不可预测结构的封装器的封装器（csh、ksh、python 等），它们在最终调用二进制文件之前会在不同级别增强环境（LD_LIBRARY_PATH、LD_PRELOAD 等）。

我曾在一个流程中使用 Linux 查找和文件命令来识别与操作系统体系结构（例如 amd64）一致的二进制可执行文件，然后在这些二进制文件上运行 ldd 来检查是否存在缺失的依赖关系；但是，由于 LD_LIBRARY_PATH 未正确设置，或者由于某些原因在发布版本中仍然打包了明显不兼容的二进制垃圾文件，这导致了太多的错误标记。

我真正需要的是在调试环境中使用 (ldd BINARY_PATH > RESULTS) 替换二进制调用的自动方法，或许可以使用一些类似于 strace 的工具，在检测到感兴趣的二进制执行时提供一个钩子。 有没有一个系统级调试器能做这样的事情？

作为最后的办法，我在考虑复制 EDA 版本的结构，用在原始二进制文件上执行 ldd 的同名封装程序替换二进制可执行文件；这种方法的运行环境应该是正确的。 明显的缺点是设置时间较长；这些工具的结构非常庞大，但我或许可以对文件进行硬链接。

你提出的问题确实在 EDA 软件移植到生产环境中很常见，特别是跨不同的 Linux 发行版或版本时。你提到的使用 ldd 的方法虽然可行，但确实存在误报和效率低下的问题。

让我们看看几种可能更有效和准确的解决方案：

1. 使用容器技术

• 这是目前最推荐的解决方案。将 EDA 工具链和所有依赖项打包到 Docker 或 Singularity 等容器中，可以确保在任何兼容的 Linux 环境中都有一致的运行环境。
• 优点：
  • 消除依赖冲突，保证运行环境一致性。
  • 简化部署和迁移过程。
  • 提供版本控制和回滚功能。
• 缺点：
  • 需要学习容器技术。
  • 对于非常庞大的 EDA 工具链，构建和管理容器镜像可能较为复杂。

2. 使用系统级调试工具

• strace 是一个很好的选择。你可以使用 -e trace=execve 选项跟踪进程执行的二进制文件，并结合 grep 和 awk 等工具提取所需的信息。
  • 例如： strace -f -e trace=execve ./your_eda_script 2>&1 | grep "execve(" | awk '{print $2}' | tr -d '"' | sort | uniq
• 优点：
  • 无需修改原始 EDA 工具链。
  • 可以捕获到实际运行时加载的动态链接库，更准确。
• 缺点：
  • 需要对 strace 和 shell 脚本有一定的了解。
  • 对于复杂的 EDA 工具链，分析 strace 输出可能比较困难。

3. 使用 Auditd

• Linux Audit 系统可以记录系统调用，包括 execve。你可以配置 Auditd 来专门记录 EDA 工具链执行的所有二进制文件，并使用 ausearch 和 aulastlog 等工具分析数据。
• 优点：
  • 对系统性能影响较小。
  • 可以记录历史执行信息，方便追溯问题。
• 缺点：
  • 配置 Auditd 相对复杂。
  • 分析 Audit 日志需要一定的专业知识。

4. 使用 LD_DEBUG 环境变量

• 设置 LD_DEBUG 环境变量可以输出更详细的动态链接器调试信息，包括加载的动态链接库路径。
  • 例如： export LD_DEBUG=libs ./your_eda_script 2>&1 | grep "find library" | awk '{print $4}' | sort | uniq
• 优点：
  • 无需额外工具，使用方便。
• 缺点：
  • 输出信息量大，难以分析。
  • 不如 strace 准确，因为可能无法捕获到所有动态链接库加载事件。

关于你的“最后办法”：

• 虽然可行，但这种方法确实存在设置时间长、维护成本高的缺点。
• 如果 EDA 工具链结构非常复杂，你可能需要编写脚本来自动化创建封装程序的过程。

建议：

• 优先考虑使用容器技术，因为它能提供最可靠和便捷的解决方案。
• 如果容器技术不可行，可以尝试使用 strace 或 Auditd 等系统级调试工具。
• 避免使用你提到的“最后办法”，因为它效率低下且难以维护。

希望这些信息能够帮助你找到解决问题的最佳方案！