【发布时间】：2023-03-18 23:10:01
【问题描述】：
我正在处理Autools front-end for a C++ library。看起来 Libtool 正在将 C 源文件添加到项目中，并且在某些平台上造成了相当多的麻烦。我们认为它会导致无法解释的崩溃，例如 Message “During startup program terminated with signal SIGKILL” from GDB。
C 源文件引起麻烦有几个原因。首先，我们只查询CXXFLAGS并设置AM_CXXFLAGS；我们不会对CFLAGS 或AM_CFLAGS 做任何事情。其次，C 文件在 C++ 项目中需要额外的选项，例如 GCC 下的 -frtti 和 -fexceptions 以及 IBM XL C/C++ 编译器下的 -qrtti 等选项。我不清楚 libtool 是否正在添加必要的选项。第三，Libtool 添加的 C 源文件在使用 Newlib 的平台上需要额外的 Posix 选项，例如 Cygwin 和 MSYS。我们的源文件不需要这些选项。
我想强制 Libtool 使用 C++ 而不是 C，但我无法找到这样做的选项或方法。我认为 Libtool 最简单的方法是使用 lt-<some file>.cpp 和 CXXFLAGS 而不是 lt-<some file>.c 和 CFLAGS，但我不知道该怎么做。
我们如何告诉 Libtool 使用 C++ 而不是 C？
一个相关的问题是How to disable C compiler in C++ Autotools project，但它只要求使用 C++ 编译器进行功能测试。
【问题讨论】：
-
如果
libtool真的在添加C 源文件，那么它们应该通过C 编译器进行编译。 C 和 C++ 是不同的语言，每一种都具有对方所缺乏的特性。一般来说，假设您可以使用 C++ 编译器成功编译 C 源代码是不安全的，如果您确实成功了，那么假设生成的二进制文件具有与从C 编译器的相同源代码。 -
但这整件事让我感到惊讶。它与LTDL有关吗？我想不出
libtool需要将任何运行时代码添加到项目中的任何其他原因。 -
@JohnBollinger - 我认为 Libtool 添加了某种包装程序来调用真实程序（或者 libtool 中的某些组件会这样做）。我只是在包装器无法编译时才意识到这一点。例如，请参阅 libtool 邮件列表中的 C++ compiler, Newlib and "implicit declaration of function '_spawnv'"。
-
不在我为 Linux、OS X 或 MinGW 构建的版本中。但同样，我可以相信，如果 LTDL 参与支持在系统上动态加载的模块，这可能会发生这种情况。
-
无论如何，您是否考虑过在
AM_CFLAGS中设置所需的标志？这不应该影响您的任何 C++ 编译，但它应该应用于涉及任何未定义自己的 C 标志的目标的 C 源代码。