【发布时间】：2019-02-25 01:06:00
【问题描述】：
我们遇到了一个奇怪的问题，我已经没有解决问题的想法了。问题是在一些运行 Visual Studio 2017 Community 的机器上，我们收到报告称我们的项目（基于 CMake）出现如下链接器错误：
17>------ Build started: Project: ndt, Configuration: RelWithDebInfo x64 ------
17> Creating Library E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.lib and object E:/NDT_3_0/19_Sept18/qualnet/RelWithDebInfo/exata_so.exp
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol edKJPOs664VT referenced in function "void __cdecl CheckLibraryLicenses(struct NodeInput*,...)
17>ndt-main-windows-x64-vc14.obj : error LNK2019: unresolved external symbol zzPIPSGJWa referenced in function main
...
17>E:\NDT_3_0\19_sep18\qualnet\bin\exata_so.exe : fatal error LNK1120: 17 unresolved externals
（抱歉，如果有错别字：出于某种原因，他们向我们发送了文本的屏幕截图，而不仅仅是文本的复制和粘贴，所以我正在转录。但是，我遗漏的部分包含没有提及尝试打开定义这些符号的lmgr.lib 时出错。）
奇怪的是，当我们对他们正在使用的同一个 Bitbucket 存储库进行全新克隆并遵循相同的构建说明时，我们无法在此处重现这些错误。我能说的唯一区别是我们的机器运行的是 Visual Studio 2017 Professional。 （虽然我当然不确定这是否真的是行为差异的原因。）
到目前为止，我们已经检查过：
- 包含未解析外部符号的库通过了 sha1sum 检查，因此他们的 Git 客户端不会损坏库二进制文件
lmgr.lib-ndt-main-windows-x64-vc14.obj文件也是如此。 - 生成的
ndt.vcxproj项目在“链接器 -> 输入 -> 附加依赖项”属性中包含（正确路径）lmgr.lib，正如预期的那样。 -
lmgr.lib文件确实定义了上述符号（由 Cygwin binutilsnm验证）。 - 在他们的机器上，无论是使用
Visual Studio 15 2017 Win64生成器并从IDE 构建，还是使用NMake Makefiles生成器并从命令提示符构建，它们都会遇到基本相同的链接器错误。两种配置都可以在我们的机器上正常运行。
我想知道是否有人对为什么某些机器可能无法找到 lmgr.lib 中的符号而我们的机器在完成链接阶段没有问题有任何想法。
（可能相关：lmgr.lib 包含 FlexNet Publisher 许可库，其中 lmgr.lib 和 ndt-main-windows-x64-vc14.obj 中的符号已被 Flexera 的 lmstrip 工具混淆。）
【问题讨论】：
标签： c++ linker visual-studio-2017