在本期“让我们变得愚蠢”中，我们遇到了以下问题：C ++库已经包含了一层代码，该代码以允许从C调用它的方式导出其功能。必须链接的独立库（连同原始C ++库和一些特定于程序的目标文件）到C程序中以产生所需的结果。
棘手的部分是，这是在内部构建的刚性构建系统的环境中完成的，并且包含几十个包含makefile的字体。这个系统有一个单独的步骤，用于将库和目标文件链接到最终的可执行文件中，但是它坚持使用gcc代替g ++，因为程序源文件都有.c扩展名，所以结果是大量的未定义符号。如果在提示符下手动粘贴命令行并用g ++替换gcc，那么一切正常。
有一个众所周知的（对于这个构建系统）make变量允许将标志传递给链接步骤，如果有一些咒语可以添加到此变量中，这会强制gcc像g ++一样行事（因为两者都只是驱动程序）。
我花了很多时间在gcc文档中搜索可以执行此操作但未找到任何看起来正确的内容，是否有人有建议？
答案 0 :(得分：1)
考虑到这样一个糟糕的构建系统，在gcc周围编写一个包装器，exec的{{1}}或gcc依赖于参数。将g++替换为此脚本，或修改/usr/bin/gcc以优先使用此脚本。
PATH答案 1 :(得分：0)
问题是C链接产生具有C名称重整的目标文件，并且该C ++链接产生具有C ++名称重整的目标文件。
你最好的选择是使用 外部“C” 在C ++构建中声明之前，C构建中没有前缀。
您可以使用
检测C ++#if __cplusplus
答案 2 :(得分：0)
非常感谢bmargulies对原始问题的评论。通过使用-v选项将运行链接线的输出与gcc和g ++进行比较并进行一些实验，我能够确定“-lstdc ++”是添加到我的链接标志的神奇成分（在适当的位置）相对于其他库的顺序）以避免未定义符号的问题。
对于那些希望在家里玩“让我们变得愚蠢”的人，我应该注意到我已经避免在C ++代码中使用静态初始化（通常是明智的），所以我没有被迫编译翻译单元包含带有g ++的main（）函数，如FAQ-Lite项目32.1所示（http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html).