相关疑难解决方法(0)

在地址清理程序的文档中（https://releases.llvm.org/7.0.0/tools/clang/docs/AddressSanitizer.html），它指出：

链接共享库时，AddressSanitizer运行时未链接，因此-Wl,-z,defs可能会导致链接错误

不仅 ASAN 如此，UBSAN 也是如此。事实证明，这对于 UBSAN 来说特别不方便，因为清理程序可以在库之间引入新的类型信息依赖关系（ https://jira.mongodb.org/browse/SERVER-49798vptr中有很多详细信息）。

我真的更喜欢使用-Wl,-z,defsUBSAN 构建。实际上，我可以通过手动将诸如-lclang_rt.ubsan_standalone-x86_64共享库的链接行之类的内容注入到编译过程中的 ubsan 构建中来实现这一点。

但这给我留下了一个棘手的问题：为什么链接驱动程序在链接共享库时不clang根据显式文档自动执行此操作？它显然可以做到这一点，因为它已经为自动获取运行时的程序做到了这一点。事实上，它明确并没有让我怀疑这样做是否存在某种问题。

• 由于某种原因，将运行时库强制ubsan到所有共享库的链接线上是否是一个坏主意？
• 它是否会以某种方式削弱消毒剂的有效性？
• 还有其他我没有看到的可怕的缺点吗？

我维护一个大型 C++ 库，我使用 pybind11 部分接触了 python。C++ 库包含单元测试，我有时会在各种清理程序下运行这些测试：asan、tsan 等。这些测试运行干净，但当然测试并不完美，您无法 100% 测试所有边缘情况。

当我使用具有特定设置、特定数据集和各种选项的库时，有一个特定的 jupyter 笔记本会崩溃，这些选项可以在纯 C++ 环境中复制，但这种复制将非常耗费人力、时间并且容易出错。

如果我面前有纯 C++，我会通过 ubsan、asan 等运行笔记本，以确保我没有看到未定义的行为或段错误。有没有办法可以将这些消毒剂（或类似的东西）应用到我的笔记本上，而无需用原始 C++ 重写所有 python 胶水？

我正在开发一种产品，该产品由多个C ++可执行文件和相互依赖的各种库组成。我正在使用GCC和-fsanitize-address。据我了解，如果我想将地址清理器与库一起使用，则必须将其构建为共享对象（这是GCC的默认选项）。因此，我认为最好的选择是-static-libasan为可执行文件静态地构建地址清理器，并为库动态地构建地址清理器。但是，当我这样做时，在构建C ++可执行文件之一时出现链接错误：

==10823==Your application is linked against incompatible ASan runtimes

这使我认为静态和动态版本的地址清除器不能与GCC混合使用，对吗？我在消毒剂GitHub页面上找不到关于此的任何信息。