Мы столкнулись со странной проблемой, и у меня закончились идеи по устранению неполадок.Проблема в том, что на некоторых компьютерах, на которых работает 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 в свойстве «Linker -> Input -> Additional Dependencies», как и ожидалось. - Файл
lmgr.lib определяет указанные символы (проверено Cygwin binutils nm). - На своих машинах они получают по существу одинаковые ошибки компоновщика, будь то использование генератора
Visual Studio 15 2017 Win64 и сборка из IDE, или использование генератора NMake Makefiles и сборка из командной строки.Обе конфигурации отлично работают на наших машинах.
Мне было интересно, есть ли у кого-нибудь идеи о том, почему некоторые машины не могут найти символы в lmgr.lib, тогда как у наших машин нет проблем с завершениемэтап связывания.
(возможно, релевантно: lmgr.lib содержит библиотеки лицензий FlexNet Publisher, где символы как в lmgr.lib, так и ndt-main-windows-x64-vc14.obj были скрыты инструментом Flexera lmstrip.)