Question

我们面临一个奇怪的问题，我用尽了所有故障排除想法。问题是，在运行Visual Studio 2017社区的某些计算机上，我们得到报告，我们的项目（基于CMake）出现链接器错误，如下所示：

@echo off
(
  for %%F in (TRSF.SUM) do (
    for "delims=" %%A in ('findstr /b /c:"88," "%%F"') do echo %%F %%A
  )
) >newfile.SUM

（很抱歉，如果有错别字：由于某种原因，他们向我们发送了文本的屏幕截图，而不仅仅是文本的复制粘贴，所以我正在转录。但是，我遗漏的部分包含没有提及尝试打开定义这些符号的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的错误。）

奇怪的是，当我们对它们使用的相同Bitbucket存储库进行全新克隆并遵循相同的构建说明时，我们无法在此处重现这些错误。我只能说的唯一区别是我们的机器运行的是Visual Studio 2017 Professional。（尽管我不确定这是否确实是行为差异的原因。）

到目前为止，我们已检查的内容：

包含未解析的外部符号的库通过sha1sum检查，因此其Git客户端不会损坏库二进制文件lmgr.lib，对于lmgr.lib文件也是如此。
按预期，生成的ndt-main-windows-x64-vc14.obj项目在“链接器->输入->其他依赖项”属性中包含ndt.vcxproj（正确的路径）。
lmgr.lib文件确实定义了提到的符号（由Cygwin binutils lmgr.lib验证）。
在他们的计算机上，无论使用nm生成器并从IDE构建，还是使用Visual Studio 15 2017 Win64生成器并从命令提示符构建，他们都会获得相同的链接器错误。两种配置在我们的机器上都能正常工作。

我想知道外面的人是否对为什么某些机器可能无法在NMake Makefiles中找到符号而我们的机器在完成链接阶段没有问题有任何想法。

（可能相关：lmgr.lib包含FlexNet Publisher许可库，其中lmgr.lib和lmgr.lib中的符号已被Flexera的ndt-main-windows-x64-vc14.obj工具混淆了。）

Answer 1

原来，当我们要求他们将Visual Studio 2017社区安装升级到最新的Service Pack版本时，链接器错误消失了。

VS 2017社区出现链接器错误，但Professional没有

1 个答案: