При использовании fstream в библиотеке я получаю ошибки компоновщика в исполняемом файле

Когда я добавляю

#include <fstream>

и попробуй использовать

std::ifstream (i.e. std::ifstream ifile(pDest))

в моей библиотеке я получаю следующие ошибки компоновщика при компиляции проекта, который использует библиотеку:

Error   2   error LNK2019: unresolved external symbol __CrtDbgReportW referenced in function "public: wchar_t * & __thiscall std::vector<wchar_t *,class std::allocator<wchar_t *> >::operator[](unsigned int)" (??A?$vector@PA_WV?$allocator@PA_W@std@@@std@@QAEAAPA_WI@Z) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\Console.lib(ZipLib.obj)  TestingZipper
Error   3   error LNK2001: unresolved external symbol __CrtDbgReportW C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(stdthrow.obj) TestingZipper
Error   4   error LNK2019: unresolved external symbol __free_dbg referenced in function "private: void __thiscall std::_Yarn<char>::_Tidy(void)" (?_Tidy@?$_Yarn@D@std@@AAEXXZ) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\Console.lib(ZipLib.obj)  TestingZipper
Error   5   error LNK2001: unresolved external symbol __free_dbg    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(xdebug.obj) TestingZipper
Error   6   error LNK2001: unresolved external symbol __free_dbg    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(locale0.obj)    TestingZipper
Error   7   error LNK2019: unresolved external symbol __malloc_dbg referenced in function "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(xdebug.obj) TestingZipper
Error   8   error LNK2001: unresolved external symbol __malloc_dbg  C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(locale0.obj)    TestingZipper
Error   9   error LNK2019: unresolved external symbol __calloc_dbg referenced in function __Getctype    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(_tolower.obj)   TestingZipper Error 10  error LNK1120: 4 unresolved externals   C:\zipprojnotworking\CPP\7zip\UI\Console\Debug\TestingZipper.exe    TestingZipper

Есть идеи, почему?


c++ visual-c++ lnk2001 lnk2019
person meds    schedule 16.12.2011    source источник
comment
Когда вы добавляете #include что?   -  person Joe    schedule 16.12.2011
comment
Мне кажется, что вы ссылаетесь на неправильный CRT. Как вы создали свой проект?   -  person ildjarn    schedule 16.12.2011

Ответы (2)


arrow_upward
3
arrow_downward

5+ лет спустя... проблема (а может и многие другие) уже решена (и забыта :) )

У вас есть 1 проект lib, содержащий приведенный выше код: я предполагаю, что он находится в файле .c(xx), а не в файле .h (входит в оба проекта) и проект app, использующий предыдущий.
Я подумал о том, какой может быть конфигурация, которая привела бы к такому поведению (проект lib отлично строится, а проект app имеет эти неразрешенные внешние файлы< /em>), и единственная корректная конфигурация: проект lib неверен. Позвольте мне подробно:

  • Один отсутствующий символ — CrtDbgReport, который говорит мне, что библиотека построена в режиме Debug.
  • The fact that the lib is building OK, tells me that either:
    1. The lib project is fine, and the error is in the app project
    2. Проект lib не подходит (и проект app может подойти, а может и нет), но это статическая библиотека, и в данном случае Файлы .obj просто «объединяются» вместе в результирующем файле .lib — он не связан, поэтому компоновщик не ищет неразрешенные внешние файлы. на данный момент, и он будет искать только тогда, когда эта библиотека будет связана с исполняемым файлом (.exe или .dll). Это подтверждается тем фактом, что я видел libcpmtd.lib(1) в журнале ошибок: использование версия статической библиотеки времени выполнения ((U)CRT) (особенно в проекте, содержащем библиотеки) имеет смысл только при создании статического приложения (обычно предназначенного для работы в < em>урезанная среда — например, в дистрибутиве «минималистическое ядро ​​Windows», где могут потребоваться только основные библиотеки, такие как: ntdll.dll, kernel32 .dll, ...).
  • Отсутствие повторяющихся символов во время компоновки (проект приложение) исключает первыйвариант.

Это лучше, поскольку мы можем упростить среду, необходимую для воспроизведения поведения. Вы можете переключить Свойства проекта -> Свойства конфигурации -> Общие -> Тип конфигурации и изменить статическую библиотеку (.lib) на динамическую библиотеку (.dll)< /эм>. Теперь, в конце, он свяжется и не выдаст ошибки при сборке проекта lib.

1 Проверьте [SO]: ошибки при связывании с protobuf 3 в MSVC 2013 для получения подробной информации о типах связывания CRT (также проверьте ссылки). Также проверьте [SO]: LNK2005 Error in CLR Windows Form подробнее о том, что происходит при создании кода C и C++.

Несколько слов о [MSDN.Blogs]: отладка против Выпуск сборок: при сборке в режиме Отладка в ваш код автоматически добавляется некоторый инструментальный код для облегчения отладки. Вот почему артефакты сборки Debug (против их аналогов в Release):

  • Имеют значительно больший размер
  • Беги медленнее

Добавление кода обычно достигается за счет различий между этапами сборки (упрощенная версия):

  • Предварительная обработка: определен макрос _DEBUG (в отличие от Release, где NDEBUG определено). Вы можете просмотреть стандартные включаемые файлы и увидеть множество директив препроцессора (в основном #ifdef) для этих макросов. Эта фаза напрямую влияет на фазу компиляции.
  • Ссылка: выбраны правильные библиотеки (которые фактически содержат этот инструментальный код).

Самое главное, что этапы компиляции (и, косвенно, предварительной обработки) и компоновки должны быть синхронизированы. Это не относится к вашему проекту lib, поэтому у вас есть несоответствие UCRT (как указано в третьем комментарии). Чтобы исправить это, либо:

  • Измените определение макроса _DEBUG / NDEBUG следующим образом: Project Properties -> C/C++ -> Preprocessor -> Определения препроцессора
  • Измените тип UCRT: Свойства проекта -> C/C++ -> Генерация кода -> Библиотека времени выполнения

Я перечислил их оба, так как не знаю, какой из них неправильный (поскольку вы хотели бы, чтобы параметры конфигурации соответствовали имени конфигурации (Отладка / Релиз)), но У меня ощущение, что это последнее.

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

person CristiFati    schedule 09.01.2017

arrow_upward
0
arrow_downward

для тех, кто, как и я, этот ответ не показался полезным, второй вариант — перейти к: Свойства проекта->Свойства конфигурации->Общие->Параметры проекта по умолчанию->Версия целевой платформы .NET и установить его до версии 4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli имеет неясный ответ от команды Microsoft, которая исправила мою проблему.

Я также добавил этот ответ к другой версии той же проблемы.

person Atarashii    schedule 28.10.2017