Странные ошибки LNK2001 после перехода на VS2019 - PullRequest
0 голосов
/ 03 августа 2020

После переноса моего кода с VS2017 на VS2019 я наткнулся на странное поведение компоновщика - похоже, что он ссылается на объекты из библиотеки stati c, которых у него не должно быть (которые, в свою очередь, относятся к символам, которые не могут быть разрешены ). По сути, я получаю следующее:

1>tools.lib(object_storage_azure.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl azure::storage::operation_context::operation_context(void)" (__imp_??0operation_context@storage@azure@@QEAA@XZ)
1>tools.lib(object_storage_azure.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) private: class Concurrency::task<void> __cdecl azure::storage::cloud_block_blob::upload_block_list_async_impl(class std::vector<class azure::storage::block_list_item,class std::allocator<class azure::storage::block_list_item> > const &,class azure::storage::access_condition const &,class azure::storage::blob_request_options const &,class azure::storage::operation_context,class Concurrency::cancellation_token const &,bool,class std::shared_ptr<class azure::storage::core::timer_handler>)" (__imp_?upload_block_list_async_impl@cloud_block_blob@storage@azure@@AEAA?AV?$task@X@Concurrency@@AEBV?$vector@Vblock_list_item@storage@azure@@V?$allocator@Vblock_list_item@storage@azure@@@std@@@std@@AEBVaccess_condition@23@AEBVblob_request_options@23@Voperation_context@23@AEBVcancellation_token@5@_NV?$shared_ptr@Vtimer_handler@core@storage@azure@@@7@@Z)
1>tools.lib(object_storage_azure.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class Concurrency::task<void> __cdecl azure::storage::cloud_block_blob::upload_from_stream_async(class Concurrency::streams::basic_istream<unsigned char>,unsigned __int64,class azure::storage::access_condition const &,class azure::storage::blob_request_options const &,class azure::storage::operation_context,class Concurrency::cancellation_token const &)" (__imp_?upload_from_stream_async@cloud_block_blob@storage@azure@@QEAA?AV?$task@X@Concurrency@@V?$basic_istream@E@streams@5@_KAEBVaccess_condition@23@AEBVblob_request_options@23@Voperation_context@23@AEBVcancellation_token@5@@Z)
... // and so forth

tools.lib - это моя собственная библиотека stati c, и она содержит много кода, при этом 99% его не используются компилируемым проектом. В частности, ничего из object_storage_azure.obj точно не используется.

Итак, запуск компоновщика с /VERBOSE дает следующее:

1>Starting pass 1
1>Processed /DEFAULTLIB:uuid.lib
1>Processed /DEFAULTLIB:msvcprt
1>Processed /DEFAULTLIB:atls.lib
1>Processed /DEFAULTLIB:kernel32.lib
1>Processed /DEFAULTLIB:user32.lib
1>Processed /DEFAULTLIB:advapi32.lib
1>Processed /DEFAULTLIB:ole32.lib
1>Processed /DEFAULTLIB:shell32.lib
1>Processed /DEFAULTLIB:oleaut32.lib
1>Processed /DEFAULTLIB:shlwapi.lib
1>Processed /DEFAULTLIB:comsuppw.lib
1>Processed /DEFAULTLIB:MSVCRT
1>Processed /DEFAULTLIB:OLDNAMES
1>Processed /DEFAULTLIB:MSVCMRT.LIB
1>Processed /DEFAULTLIB:MSCOREE
1>
1>Searching libraries
1>    Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\winhttp.lib:
1>    Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\ws2_32.lib:
...
1>    Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\kernel32.lib:
1>    Searching C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x64\odbccp32.lib:
1>    Searching C:\***my-path***\tools.lib:
1>      Found "public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ)
1>        Referenced in stdafx.obj
1>        Loaded tools.lib(treescan_json.obj)            <--------- O_O
1>      Found "public: virtual char const * __cdecl std::bad_weak_ptr::what(void)const " (?what@bad_weak_ptr@std@@UEBAPEBDXZ)
1>        Referenced in stdafx.obj
1>        Loaded tools.lib(object_storage_azure.obj)     <--------- O_O
...

В основном, по какой-то загадочной причине некоторые ссылки на STL были разрешено (в противном случае не упоминалось) объектным файлам в моем stati c lib (и те, которые впоследствии были втянуты в целый мир вещей, которые не могут быть разрешены).

Не уверен, связано ли это, но проект скомпилирована /clr dll; все использует набор инструментов v142 и 10.0.17763.0 SDK.

Как правильно решить эту проблему?

1 Ответ

0 голосов
/ 06 августа 2020

Это происходит потому, что компоновщик ищет определенные символы (например, std::exception::what), которые обычно вставляются (но не когда действует /clr), и находит их в произвольном объектном файле библиотеки c пользователя (вытягивая все зависимости, которые имеет указанный объектный файл). Переход на VS2019 просто изменяет порядок объектных файлов в указанной библиотеке. Подробности смотрите здесь .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...