Internet上有许多有关“缺少mspdb140.dll”的问题,以及其他有关缺少“ mspdb *” DLL的类似问题。对此发布了几种不同的解决方案,包括:
<msvc-install-dir>\<subpath>
就我而言,我已经在docker容器中使用了msvc 2019安装程序的构建工具,然后为msvc 2017和2019安装了这两个构建工具。如果然后转到C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64
,则有两个文件夹: x64
和x86
。如果我编写powershell命令ls -Recurse -Filter "*mspdb*"
,则会得到以下输出:
Directory: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64
mspdb140.dll
mspdbcmf.exe
mspdbcore.dll
mspdbsrv.exe
mspdbst.dll
Directory: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64\1033
mspdbcmfui.dll
尽管HostX64\x86
目录中没有这些文件。如果我以x64为目标进行构建,那么一切都很好,但是以x86为目标,则发布和调试构建都会出错。发布版本具有:
ERROR: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\cl.exe
...
c1xx: fatal error C1356: unable to find mspdbcore.dll
并且调试版本具有:
ERROR: C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64\x86\cl.exe
...
c1xx: fatal error C1356: unable to find mspdb140.dll
这些构建使用Qt和Qbs,并且Qbs使用vcvarsall.bat查找所需的环境变量。当安装了多个msvc工具链时,Qb中存在一个错误,这使得Qb总是选择最新的。要解决此问题,我手动移动vcvarsall.bat并在每个构建作业中将其替换为:
call %~dp0vcvarsall_real.bat %1 store 10.0.17134.0 -vcvars_ver=14.16.27023 || exit /b 1
这迫使vcvarsall选择我想要的工具链14.16.27023。
通过简单地复制x64目标(mspdbcmfui.dll
除外)存在的DLL和EXE文件,我设法解决了两个编译错误。正如我正在尝试的那样,没有理由不复制最后一个DLL。即使程序可以编译,我也不是很清楚自己在做什么,这些文件在哪里使用,或者为什么某些目标缺少它们!不必在构建环境中手动复制文件会更好。
我还检查了Visual Studio 2017 Professional的本地安装,然后对于HostX64 \ x64,我具有相同的文件名,但是对于HostX64 \ x86,我得到了以下输出:
C:\Program Files (x86)\Microsoft Visual Studio\2017\WDProfesional\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x86
...
mspdb140.dll
mspdbcore.dll
只有两个DLL!
在docker映像中,我还具有用于MSVC 2019的构建工具,并且所有主机和目标组合都具有所有DLL和EXE。
总结:
答案 0 :(得分:0)
我仍然希望有人能更多地解释这些文件为什么存在,如何正确使用它们,为什么在某些地方丢失这些文件以及Visual Studio似乎能够即使丢失的文件也可以编译。同时,我发现了这一点:
我已经安装了MSVC 2019的构建工具,因此我转到文件夹C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64
并运行了以下powershell命令:
(ls -Recurse "mspdb*").FullName | % { Get-FileHash $_ } | Sort-Object -Property Hash
并获得以下输出:
Hash Path
--------------------------------------------------------------------------------------------------------------------------------------------
658D21DF98781D7C137FA213C3F3C2222C5D20A0F75BEB4929703406241379FA C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbcmf.exe
658D21DF98781D7C137FA213C3F3C2222C5D20A0F75BEB4929703406241379FA C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbcmf.exe
9664EE9A457B444E0D5A2F6A73A896375966BCF3864BBCD6B76AFEF496EC954C C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbcore.dll
9664EE9A457B444E0D5A2F6A73A896375966BCF3864BBCD6B76AFEF496EC954C C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbcore.dll
A056C5CC109CB6BFABBA3982E5739B57C2C6AEBEBDF41FB6DD17586ED4FA7F13 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbsrv.exe
A056C5CC109CB6BFABBA3982E5739B57C2C6AEBEBDF41FB6DD17586ED4FA7F13 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbsrv.exe
C48FC0A0BE36C70974CD180DD0DB22BB1EA84585BBE0B23583C6FEDCAEA0C76F C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\1033\mspdbcmfui.dll
C48FC0A0BE36C70974CD180DD0DB22BB1EA84585BBE0B23583C6FEDCAEA0C76F C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\1033\mspdbcmfui.dll
E6F6DF7DAD04699078D14D02BA57A19E332367507B860E03356AF2EEA86C3D68 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdb140.dll
E6F6DF7DAD04699078D14D02BA57A19E332367507B860E03356AF2EEA86C3D68 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdb140.dll
ECC40C0574AC6B93E3ACFC3EB95882D5391A2AC10E9ACC4444D418E5D5014135 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x86\mspdbst.dll
ECC40C0574AC6B93E3ACFC3EB95882D5391A2AC10E9ACC4444D418E5D5014135 C:\BuildTools\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\mspdbst.dll
以mspdb
开头的所有文件在x86
和x64
之间都是相同的。如果我在Hostx86
文件夹中尝试相同的操作,则目标之间的文件也完全相同,但与其他主机相比却有所不同。
我认为对于MSVC 2017,同一主机的不同目标也可以安全使用这些文件。复制这些文件后,我的编译成功了,所以不会完全错误!