Противоречивые библиотеки времени выполнения в проекте Visual C++ DLL

Question

Противоречивые библиотеки времени выполнения в проекте Visual C++ DLL

Я только что попытался создать x64 C++ DLL с использованием Visual C++ 2012. Это простая DLL, связывающая один другой статический сторонний.lib файл. Я получаю следующее предупреждение:

предупреждение LNK4098: defaultlib 'LIBCMT' конфликтует с использованием других библиотек; использовать /NODEFAULTLIB: библиотека

Кажется, что другая библиотека использует параметр компоновщика /MT (многопоточная статическая среда выполнения), в то время как моя DLL (и все другие проекты, импортирующие мою DLL) использует /MD (многопоточная среда выполнения DLL). Я не могу согласовать это, поскольку сторонняя библиотека поставляется как есть, и изменение моей DLL создаст такую же проблему во всех проектах, использующих мою DLL.

Я прочитал несколько страниц из MS и форумов об этой проблеме. Но ни одна из этих страниц не объяснила, в чем именно проблема.

Что я не понимаю:

Какой вред связывание кода, который использует другой вариант времени выполнения (кроме траты памяти)? Некоторые люди говорят, что это можно игнорировать, некоторые говорят, что это не так.

Можно ли использовать /NODEFAULTLIB[:library]? В документации говорится, что она "удалит указанную библиотеку или библиотеки из списка библиотек, которые она ищет при разрешении внешних ссылок". Какую библиотеку я должен добавить как ": библиотека" и каким образом это решит проблему?

1

c++ visual-c++ dll linker visual-c++-runtime

Источник

user1421332 31 окт '13 в 16:46

2 ответа

Решение

Например, передача типов STL (например, std::string) может привести к серьезным сбоям из-за различий во внутренней структуре объекта и / или в использовании памяти

См. Почему происходит сбой этой программы: передача std::string между DLL

3

Источник

user2157240 31 окт '13 в 16:57

Другие вопросы по тегам c++ visual-c++ dll linker visual-c++-runtime

user227322 31 окт '13 в 16:54 2013-10-31 16:54 · Accepted Answer · 2013-10-31 16:54

Конфликтующие библиотеки времени выполнения могут вызвать серьезные проблемы, если вы совместно используете объекты среды выполнения C (такие элементы, как FILE*) или разделяете выделения памяти (выделяя память в одной части и освобождая ее в другой). Я бы не стал их "соединять", чтобы избежать странных проблем и сбоев.

Вместо этого, если вы не можете изменить сборку библиотеки или вашей dll, я бы обернул библиотеку внутри dll интерфейсом C only, который не пропускает ни один объект времени выполнения C, или потребовал бы, чтобы вы освободили память вне dll, которая была создано внутри.