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

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

1 голос
/ 16 декабря 2011

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

#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

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

Ответы [ 2 ]

3 голосов
/ 10 января 2017

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

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

  • Один отсутствующий символ - CrtDbgReport, который говорит мне, что библиотека встроена в режим Debug .
  • Тот факт, что библиотека работает нормально, говорит мне, что либо:
    1. lib proj в порядке, и ошибка в proj приложения.
    2. lib proj не в порядке (и приложение proj может или не может быть в порядке), но это статическая библиотека - и в этом случае файлы .obj просто " "объединены вместе в результирующий файл .lib - он не связан , поэтому компоновщик не ищет неразрешенные внешние элементы на этом этапе и будет искать только тогда, когда эта библиотека будет связана в исполняемый файл ( .exe или .dll ). Это подтверждается тем фактом, что я увидел libcpmtd.lib 1 в журнале ошибок: использование статической runtime library (CRT) версии (особенно в Проект, содержащий библиотеки) имеет смысл только при создании статического приложения (обычно предназначенного для работы в раздетой среде - например, в "Windows minimalistic core" , где это может понадобиться только основные библиотеки, такие как: ntdll.dll , kernel32.dll , ...).
  • Тот факт, что во время ссылки (app proj) не было дублированных символов, исключает 1-й вариант.

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

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

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

  • имеют значительно больший размер.
  • бежать медленнее.

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

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

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

  • изменить определение макроса _DEBUG / NDEBUG с: Свойства проекта -> C / C ++ -> Препроцессор -> Определения препроцессора
  • изменить тип CRT с: Свойства проекта -> C / C ++ -> Генерация кода -> Библиотека времени выполнения

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

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

0 голосов
/ 28 октября 2017

для тех, кто, как я, этот ответ не прозвучал как полезный, второй вариант - перейти к: Свойства проекта-> Свойства конфигурации-> Общие-> Стандартные настройки проекта -> .NET Target Framework Version установите его на v4.0

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

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

...