是否有解决未定义参考/未解决符号问题的一般准则？

我有几个"未定义的引用"(在链接期间)和"未解析的符号"(在dlopen之后的运行时)我工作的问题.它是一个相当大的makefile系统.

是否有一般规则和指南来链接库和使用编译器标志/选项来规避这些类型的错误？

如果你使用MSVC:

你不能通过设置一个标志来逃避这种类型的错误:它意味着一些单位(.cpp)不具有声明的标识符的定义.它肯定是由某个地方缺少包含或缺少对象定义(通常是静态对象)引起的.

在开发过程中,您可以遵循这些准则(来自这些文章),以确保您的所有cpp包含他们需要的所有标题,但不再包括:

每个cpp文件首先包含自己的头文件.这是最重要的指导方针; 其他一切都来自这里.此规则的唯一例外是Visual Studio中的预编译头包含; 那些总是必须是文件中的第一个.有关本文第2部分中预编译头文件的更多信息.

头文件必须包含解析它所需的所有头文件.这与第一条准则密切相关.我知道有些人试图永远不会在头文件中包含头文件声称效率或类似的东西.但是,如果在解析头文件之前必须包含文件,则必须将其包含在某处.将它直接包含在头文件中的优点是我们总是可以决定引入我们感兴趣的头文件,并且我们保证它将按原样工作.我们不必玩"猜你需要的其他标题"游戏.

头文件应该具有解析它所需的最少数量的头文件.之前的规则说您应该在头文件中包含所需的所有包含.这条规则说你不应该拥有任何东西.显然,首先要删除(或者不首先添加)无用的include语句.然后,使用尽可能多的前向声明而不是包含.如果您拥有的只是类的引用或指针,则不需要包含该类的头文件; 前向参考将做得很好,效率更高.

但是正如评论者的建议,似乎你正在使用g ++ ......

设置一个构建系统,其中X依赖于Y,这取决于Z有用.当你进入圈子(Z依赖于X)时,事情变得丑陋.

通常,订单库被链接("-lZ -lY -lX"vs"-lX -lY -lZ")导致悲伤.更少见的是,您在搜索路径上的多个位置具有相同的库名称,或者您对尚未重新编译的过期版本具有相同的链接.

"nm --demangle"可以让你看到定义/使用的东西.

"ldd"可用于查看您所依赖的动态库.

gcc/g ++标志-print-file-name = LIBRARY可以帮助确切地追踪正在使用的库.

事后的想法:(因为你问的是规则/指导方针.)

可以设置一个makefile系统,以便:

如果module = D取决于模块A,B和C.

然后尝试使module = D首先制作模块A,B和C.

而且,更重要的是,module = D会自动确定其库(-lA等),库路径(-LA)以及模块A,B和C的makefile中的路径(-IA).

这可能会有点毛茸茸的设置.上次我这样做时,我倾向于仅缓存信息而不是分支过多的make子进程.加上makefile-imports和一个小的perl脚本来删除重复项.Kludgey,我知道.(那些不想花时间在基础设施上的人.)但是可以做到.

然后,我再次使用GNU-make,它有一些扩展.