如何强制 gcc 像 g++ 一样链接？
在这一集中的“让我们变得愚蠢”中，我们遇到了以下问题：C++ 库被一层代码封装，该代码以允许从 C 调用它的方式导出其功能。这导致了一个单独的库必须链接（连同原始 C++ 库和一些特定于程序的目标文件）到 C 程序中才能产生所需的结果。
棘手的部分是，这是在内部构建的严格构建系统的背景下完成的，并且实际上由数十个包含 makefile 组成。该系统有一个单独的步骤用于将库和目标文件链接到最终的可执行文件中，但它坚持在这一步中使用 gcc 而不是 g++，因为程序源文件都有 .c 扩展名，因此结果是大量未定义的符号。如果在提示符下手动粘贴命令行并将 g++ 替换为 gcc，则一切正常。
有一个众所周知的（对于这个构建系统）make 变量，它允许将标志传递到链接步骤，如果可以向此变量添加一些咒语以强制 gcc 像 g++ 那样运行，那就太好了（因为两者都只是驱动程序）。
我花了很多时间在 gcc 文档上寻找可以做到这一点的东西，但没有找到任何看起来正确的东西，有人有建议吗？
In this episode of "let's be stupid", we have the following problem: a C++ library has been wrapped with a layer of code that exports its functionality in a way that allows it to be called from C. This results in a separate library that must be linked (along with the original C++ library and some object files specific to the program) into a C program to produce the desired result.
The tricky part is that this is being done in the context of a rigid build system that was built in-house and consists of literally dozens of include makefiles. This system has a separate step for the linking of libraries and object files into the final executable but it insists on using gcc for this step instead of g++ because the program source files all have a .c extension, so the result is a profusion of undefined symbols. If the command line is manually pasted at a prompt and g++ is substituted for gcc, then everything works fine.
There is a well-known (to this build system) make variable that allows flags to be passed to the linking step, and it would be nice if there were some incantation that could be added to this variable that would force gcc to act like g++ (since both are just driver programs).
I have spent quality time with the gcc documentation searching for something that would do this but haven't found anything that looks right, does anybody have suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
考虑到如此糟糕的构建系统，请根据参数编写一个围绕
gcc的包装器，使exec的gcc或g++依赖于参数。将/usr/bin/gcc替换为此脚本，或者修改您的PATH以优先使用此脚本而不是真正的二进制文件。Considering such a terrible build system write a wrapper around
gccthatexec'sgccorg++dependent upon the arguments. Replace/usr/bin/gccwith this script, or modify yourPATHto use this script in preference to the real binary.问题在于 C 链接生成具有 C 名称修饰的目标文件，而 C++ 链接生成具有 C++ 名称修饰的目标文件。
你最好的选择是使用
外部“C”
在 C++ 版本中的声明之前，并且 C 版本中没有前缀。
您可以使用以下命令检测 C++
The problem is that C linkage produces object files with C name mangling, and that C++ linkage produces object files with C++ name mangling.
Your best bet is to use
extern "C"
before declarations in your C++ builds, and no prefix on your C builds.
You can detect C++ using
非常感谢 bmargulies 对原始问题的评论。通过使用 -v 选项比较使用 gcc 和 g++ 运行链接行的输出并进行一些实验，我能够确定“-lstdc++”是添加到我的链接标志中的神奇成分（在适当的位置）相对于其他库的顺序）以避免未定义符号的问题。
对于那些希望在家玩“让我们变得愚蠢”的人，我应该注意，我已经避免在 C++ 代码中使用任何静态初始化（通常是明智的），因此我没有被迫编译翻译单元包含 g++ 的 main() 函数，如 FAQ-Lite (http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html) 的第 32.1 项所示。
Many thanks to bmargulies for his comment on the original question. By comparing the output of running the link line with both gcc and g++ using the -v option and doing a bit of experimenting, I was able to determine that "-lstdc++" was the magic ingredient to add to my linking flags (in the appropriate order relative to other libraries) in order to avoid the problem of undefined symbols.
For those of you who wish to play "let's be stupid" at home, I should note that I have avoided any use of static initialization in the C++ code (as is generally wise), so I wasn't forced to compile the translation unit containing the main() function with g++ as indicated in item 32.1 of FAQ-Lite (http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html).