Несовместимость dll, lib и a между компиляторами

#cpp #c #dll #lib #extern

Мне бы хотелось разобраться в вопросе (не)совместимости между различными компиляторами
C/C++. Часто оказывается, что между собой несовместимы даже разные версии одного и
того же компилятора. Доступной и детальной информации по этой теме мне найти не удалось.

Вопросы такие:

1) Я знаю, что с совместимостью компиляторов C++ все очень плохо, потому что язык
слишком переусложнен, имеет бесконечное количество тонкостей, исключений из правил
и пунктов, которые определяются реализацией. Поэтому я не очень понимаю, зачем используют
всякие export "C" и extern "C", если двоичные файлы (например, lib) практически всегда
оказываются совместимы лишь с тем компилятором, которым они сделаны. Так в чем смысл?

2) Если разработка lib, dll и a файлов ведется с использованием языка C, то как в
этом случае обстоят дела с совместимостью? Все так же плохо, как если бы разработка
велась на C++? Или нет?

3) Есть ли способы делать двоичные библиотеки максимально совместимыми? Чтобы написанная
однажды библиотека dll могла быть подключена в самых разных языках без боли и страданий?
    

Ответы

Ответ 1

Несовместимость бинарных модулей (далее, для краткости, просто "модулей"), произведенных
разными компиляторами, определяется в основном следующими тремя аспектами:


Разные правила декорирования имен экспортируемых символов
Разное устройство объектов стандартной библиотеки
Разные правила расположения полей структур в памяти


Первый пункт характерен фактически только для С++: в Си существует набор характерных
для конкретной аппаратной платформы соглашений о вызове (например, stdcall, fastcall
и cdecl для x86), которые довольно четко прописывают правила декорирования имен. Второй
пункт относится и к Си и к С++, но в Си не очень много "объектов стандартной библиотеки"
- в голову приходит только FILE*, и экспортировать его через границы модулей нет никакого
смысла. 

Таким образом да, действительно можно сказать, что С++ "хуже" чем Си в плане бинарной
совместимости. Это разумеется не значит, что не нужно на нем писать, это лишь значит,
что на границе модулей нужно использовать интерфейс в стиле Си (либо использовать стандартизированный
объектно-ориентированный интерфейс, например Component Object Model в Windows). 


  Есть ли способы делать двоичные библиотеки максимально совместимыми? Чтобы написанная
однажды библиотека dll могла быть подключена в самых разных языках без боли и страданий?


Использование DLL на С/С++ в других языках это больше чем вопрос бинарного интерфейса
(например, в них может просто не быть концепции заголовочных файлов, указателей и т.п.),
но обычно да, библиотека с интерфейсом в стиле Си может быть использована и из других
языков с тем или иным количеством дополнительных телодвижений. 

Рекомендации для обеспечения максимальной бинарной совместимости: 


Экспортируйте через границы бинарного модуля только простые функции с припиской extern
"C" (т.е, никаких классов, шаблонов, перегруженных функций, пространств имен и т.п.)
Передавайте через границы модулей только простые типы, указатели на них и указатели
на функции.
Если все же передаете структуры, сделайте первым членом структуры ее размер. Это
позволит, если вы натолкнетесь на различия по выравниванию полей, обнаружить несоответствие
в общем размере структуры и хотя бы нормально вернуть ошибку. 
Не передавайте через границы модулей объекты стандартной библиотеки, например указатели
FILE*.
Блоки динамической памяти должны освобождаться всегда в том же модуле, в котором
были выделены. Т.е., если библиотека возвращает программе-клиенту указатель на блок
памяти, выделенный malloc внутри себя, она должна предоставлять специальную функцию
для его освобождения (вызывающую внутри себя free), вместо того, чтобы полагаться на
вызов free в программе-клиенте.


Ответ 2

Толстый троллинг по поводу "недостатков" языка С++ продолжается. Ну что же, ринемся
на защиту детища Страуструпа.


  1) Я знаю, что с совместимостью компиляторов C++ все очень плохо,


С совместимостью компиляторов С++ все очень хорошо, гораздо лучше, чем с совместимостью
компиляторов с каких-либо других языков. Вплоть до того, что многие языки имеют компилятор
только под одну платформу и/или от одного производителя. Конечно, такой подход улучшает
совместимость, но ухудшает переносимость и тормозит развитие. При отказе единственного
производителя компилятора от поддержки языка 100500 разработчиков повисают в воздухе.
Достаточно вспомнить отказ даже такого гиганта как Микрософт от обратной совместимости
в языке Visual Basic при переходе от версии VB6 к версии VB.net.


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


Язык С++ не переусложнен. Просто в языке С++ не включена "защита от дурака". В награду
за не включенную "защиту от дурака" пользователи имеют возможность делать то, что им
нужно, а не то, что позволяет им язык. Чтобы пользоваться всеми возможностями языка
С++ недостаточно выучить синтаксис С++ по первому изданию книжки Страуструпа. Надо
еще читать книжки, которые выходят по мере развития языка и в которых обсуждаются как
раз те новые возможности, которые некоторых разработчиков приводят к созданию крашащегося
кода, а другим разработчикам позволяют съэкономить 100500 часов рабочего времени. Внесение
в язык С++ новых возможностей (например шаблонов) порождает взаимодействие этих новых
возможностей со старыми возможностями (например с классами). Это взаимодействие может
служить как источником ошибок, так и источником новых идей и подходов. Многие достойные
люди занимаются исследованиями в этих направлениях и публикуют свои результаты исследований.
Изучая эти исследования можно избежать ошибок и воспользоваться новыми подходами. Еще
раз повторю что в языке С++ не включена "защита от дурака". И поэтому, чтобы не делать
ошибок в языке С++, надо точно понимать, что именно ты делаешь.


  Поэтому я не очень понимаю, зачем используют всякие export "C" и
  extern "C", 


Как тут правильно заметили это отключает манглинг имен.


  если двоичные файлы (например, lib) практически всегда
  оказываются совместимы лишь с тем компилятором, которым они сделаны.
  Так в чем смысл?


Под совместимостью различных компиляторов языка С++ имеется ввиду совместимость на
уровне исходного текста. Двоичную совместимость объектников, бинарников и библиотек
lib никто и никогда не гарантировал. Кстати, это относится и к другим языкам (за исключением
языков с виртуальными машинами, но там за это платят тем, что приходится за собой таскать
все тупиковые решения и ошибки ради обратной совместимости). 


  2) Если разработка lib, dll и a файлов ведется с использованием языка
  C, то как в этом случае обстоят дела с совместимостью? Все так же
  плохо, как если бы разработка велась на C++? Или нет?


Кстати, никто не гарантировал совместимость объектников, бинарников и библиотек lib
для языка Си. Трансляторы с языка Си от разных производителей производят объектники
разного формата. Ну и что в этом такого?


  3) Есть ли способы делать двоичные библиотеки максимально
  совместимыми? Чтобы написанная однажды библиотека dll могла быть
  подключена в самых разных языках без боли и страданий?


Если в системе Windows dll имеет "pure Си" интерфейс, то ее можно вызвать из многих
других языков. Количество боли и страданий при этом зависит от разработчика интерфейса
между dll и этим самым языком, из которого dll вызывается. Собственно языки С/С++ к
этому не имеют никакого отношения.

UPD1:


  Я не начинал толстый троллинг по поводу недостатков C++, просто это
  мое мнение, которое основывается на определенном опыте работы с этим
  языком, в том числе в международных группах разработчиков. – Максим 2
  минуты назад


Уважаемый Максим, количество использующих язык С++ разработчиков в мире (в том числе
в международных группах разработчиков) убедительно показывает, что язык C++ вполне
жизнеспособен. Если бы это было не так, то от языка С++ давно бы отказались, как отказались
в свое время от 100500 других языков.

UPD2:


  С тем, что С++ жизнеспособен, никто не спорит. Но все-таки в нем
  действительно много разных тонкостей и хитростей. – HolyBlackCat 10
  секунд назад


Как я уже сказал, все эти "тонкости и хитрости" это следствие того, что новые возможности
добавляются в язык и на уровне транслятора отсутствуют семантические и синтаксические
ограничения на использование этих новых возможностей. Также  на уровне транслятора
отсутствуют семантические и синтаксические ограничения на взаимодействие новых возможностей
со старыми возможностями. Это, с одной стороны, добавляет мощи. А с другой стороны,
ограничения на использование новых средств должны храниться в голове программиста,
а не прошиваются в синтаксисе языка.

В любом случае, все, кому С++ кажется слишком сложным/непонятным/переусложненным/плохо
совместимым может пользоваться любыми другими языками вместо того, чтобы перечислять
мнимые недостатки С++. Потому что все эти якобы недостатки С++ это вовсе не недостатки,
а это такой подход при котором транслятор не мешает Вам выстрелить себе в ногу, но
зато дает возможность выстрелить на 100500 километров при правильном использовании.
На свете есть 100500 трансляторов, которые мешают программисту выстрелить себе в ногу,
но зато и ограничивают возможности.

UPD3:

Извините за частое употребление идиомы 100500, но уж очень она тут подходит. :-)

Как хранятся глобальные const данные в библиотеках C++

#cpp #dll #lib #namespace #const

Есть статическая библиотека (.lib/.a).
В этой библиотеке находится файл с namespace, в котором две const переменные с публичным
и приватным ключом:

namespace dsa
{
   const std::vector private_key = {...}
   const std::vector public_key = {...}
}


Публичный ключ используется в динамической библиотеке (.dll/.so), путем подключения
исходной статической библиотеки.

Приватный ключ используется в исполняемом файле, путем подключения исходной статической
библиотеки.

Поскольку статическая библиотека является слепком .obj файлов единиц трансляции,
то оба ключа будут в ней, это понятно.

А вот будет ли в публичную динамическую библиотеку (.dll/.so) попадать информация
о приватном ключе, если в ней не вызываются функции, использующие его?

Как вообще организовано хранение подобных данных (глобальные const НЕ POD данные)
в windows/linux файлах динамических библиотек?
    

Ответы

Ответ 1

Да в *.dll попадут оба ключа. В этом отношении, линковка dll ни чем не отличается
от exe. Проверить наличие переменной можно попросив линкер генерировать map файл. 

Линкер может выкинуть (при подключении .lib файла), только единицу трансляции целиком
(соответствующею одному .obj/.cpp, из тех, что попали в .lib), и только в случае, если
нет ссылок ни на один символ из этой единицы трансляции. Но ссылка на публичный ключ
используется в любом случае...

Самый надежный способ - написать две статические либы: с приватным и с публичным
ключами по отдельности, тем более, что они должны обеспечивать разную функциональность:
передача и прием сообщений.


Ответ 2

Исходя из ответа @Chorkov провел несколько тестов с использованием /MAP и результаты
огорчили.
Решил хранить приватный ключ в отдельном файле, исключив его таким образом из кода
вообще.

Возможно ли подключить библиотеки .NET Framework в .NET Core 2.1.4?

#c_sharp #net #net_core #lib #sfml

Нужно подключить библиотеку в виде DLL, но у меня не получается. Возможно ли это?
    

Ответы

Ответ 1

В общем случае нельзя. Например, потому, что .NET Core является подмножеством .NET
Framework. Выход: перевести библиотеку на ту версию .NET Standard, которая поддерживает
.NET Core.

Многие 3rd party библиотеки потихоньку обзаводятся соответствующии версиями.

Upd

Говорят еще, что если библиотека не содержит Windows-specific вызовов, то ее можно
зареференсить прямо так. Но я не проверял. Какую библиотеку вы пытаетесь подключить
и что именно у вас не получается?

P.S. Ну и заодно привяжу "обратный" вопрос: Использование Net.Core библиотек в Net.Framewok

Разница использования библиотек поддержки?

#java #android #lib #android_support_library #android_library

При чтении статей сталкиваюсь с тем, что пишут нужно подключить такую или такую библиотеку
поддержки. Я немного почитал, чтоб постараться от сего зависит какую библиотеку нужно
подключать.

Я так понял, что в зависимости для какого апи пишешь то такую библиотеку и нужно
использовать. 

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

android.support.v4
android.support.v13


Я так понимаю, что 

android.support.v4


Можно вовсе удалить так как 

android.support.v13


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

Ответы

Ответ 1

К сожалению все неправильно.

Во первых, версией библиотеки считается трехзначный номер в конце (как 24.3.0), а
не число, что идет после v. в названии библиотеки. Эти числа - это до какого минимального
API эта библиотека поддержки собственно оказывает поддержку. Так, v.4 значит, что библиотека
поддержки будет работать на устройствах с API4 и выше.

Использовать нужно версию библиотеки не менее чем minSDKversion проекта и равную
или более, чем compileSDKversion (targetSDKversion) а крайне  желательно - последнюю
стабильную (сейчас это 24.3.0), так как с каждой новой версией вносятся фиксы в существующие
классы и дополняются новые классы или методы. При этом смотреть соответствие API нужно
по мажорному номеру библиотеки (здесь 24.3.0 - для compileSDKversion API24).  

Ознакомиться с изменениями, вносимыми в библиотеки поддержки с каждой новой ревизией
можно на официальном сайте разработчика Android - здесь указано, какие именно изменения
и дополнения были внесены с каждой ревизией и в какие именно из библиотек поддержки
(так в ревизии 24.3.0 были внесены изменения в библиотеки v4, v7 (в подбиблиотеки AppCompat,
MediaRouter, Preferences, RecyclerView) , Design.

библиотеки support.v4 , support.v7 и тд - это разные библиотеки, с различными классами
поддержки и выполняемыми функциями и они не взаимозаменяют друг друга по принципу большей
версии. С полным списком библиотек поддержки Google и их назначением и функциями вы
можете ознакомиться на все том же официальном сайте разработчика Android.

Например, библиотека com.android.support:support-v4:24.3.0 - библиотека поддержки
с минимальным API, на котором она работает API4 и версией самой библиотеки - 24.3.0.
Список классов и функций этой библиотеки можно посмотреть здесь. Как видите, это совсем
не то же, что библиотека com.android.support:support-v7, в которую входит вообще несколько
отдельных библиотек, как ApppCompat, CardView и тд.

PS: никакой библиотеки support.v21 у Google не наблюдается ..

Как работает компоновка С-приложений?

#c #dll #компиляция #lib #компоновщик

Компилятор выполняет сборку объектных файлов (.obj) в каждом из которых (в начале?)
содержится таблица символов, где хранится все глобальные переменные, их значения (если
они есть) и адреса объявленных функции. Что же представляет собой остальное содержимое
объектного файла? Скомпилированный код. Как он выглядит, если у нас несколько функций?
Не сливается же это всё в единую последовательность команд...

Как устроена статическая линковка библиотек? Неразрешённые символы таблицы символов
компоновщик ищет в указанных библиотеках. Так понимаю, в библиотеке тоже должно быть
указано где находится искомая функция и её размер. Далее функция включается в исполняемый
файл. Выходит, .lib не нужно за собой таскать раз функция уже в .exe?

Как устроена динамическая линковка библиотек? ОС должна используя таблицу импорта
найти нужные функции в .dll и загрузить эти функции в оперативную память процесса?

Пожалуйста, можно объяснить поподробнее обо всех этих вещах и том, что посчитаете
относящимся к этому вопросу.



CORRECTED: Уточняю свои вопросы:


Объектные файлы. Компилятор выполняет создание объектного файла, который в общем
виде представлен заголовком, содержащим различную информацию о программе, и скомпилированным
кодом, который так же зависит от RTL и, в зависимости от компилятора, содержит те или
иные ссылки на функции из библиотек RTL. Заголовок так же содержит таблицу символов
(где находится информация обо всех методах и глобальных переменных (размер, тип, адреса
и т.п.), а так же, в случае С++, описания методов классов, запись названий которых
осуществляется при помощи декорирования имён ввиду некоторых ограничений на символы
(в случае dll, это затрудняет использование классов при явной компоновке, как я понял)).
Скомпилированный код просто представлен сплошными инструкциями, которые как-то разделяются
по функциям, на начала которых указывают символы в таблице символов. Когда объектных
файлов несколько, таблицы символов сливаются, как и код, а из повторяющихся символов
выбирается самый "массивный". Верно ли? Чем вы можете дополнить это?.
Статическая компоновка. Неразрешённые символы из таблицы символов объектного файла
компоновщик ищет в подключаемых библиотеках. В случае статической компоновки .lib файл
используется лишь как ресурс для функций, откуда копируются в целевой .exe их содержимое
(т.е. .lib за собой таскать не надо?).
Динамическая компоновка. При динамической линковке, компоновщик помечает неразрешённые
символы как IOU ("я тебе должен") (ищет ли он их определения в указанных .dll? надо
же быть уверенным, что такая .dll, которую указал пользователь вообще существует и
в ней есть этот метод. Разве нет?). При запуске .exe ОС подключает нужные .dll (ищет
их в нужных местах) и загружает в память. Только, вроде как, при неявной компоновке
если какая-то .dll уже есть в памяти, она не будет загружена снова. Но как ОС знает
по какому адресу эта .dll загружена? Методы заменяются на ссылки на функции загруженной
.dll или как? При явной загрузке все функции .dll вроде просто выгружаются в память
на ровне с функциями самого .exe и в таблице данных есть адреса этих функций в оперативной
памяти - или как это вообще выглядит? При передаче переменной в метод её имя заменяется
на адрес из блока данных? Как это выглядит?

    

Ответы

Ответ 1

Извините конечно, но на тему ваших вопросов можно целую книгу написать...

Если очень грубо, то формат объектного файла в целом описывается стандартом ELF -
Executable & Linkable File - по сути это файл с неким заголовком и произвольным набором
секций, именование секций вообще говоря зависит от платформы. Для старых Windows программ
формат объектных файлов описывается COFF - Common Object File Format - структурно формат
схож с ELF, но он более Windows ориентирован, в то время как ELF - кроссплатформенный.

Если охота поразбираться в кишках - то велкам сюда

Почему требуется QtCore.dll если уже есть QtCore.lib?

#cpp #qt #dll #lib

В проекте С++ (который компилируется в динамическую библиотеку) используется библиотека
Qt, поэтому в Linker->Input добавлена статическая библиотека QtCore4.lib; почему во
время использования проектной dll требуется также QtCore4.dll?
    

Ответы

Ответ 1

Проблема состоит в том, что файл с расширением lib совершенно не обязан содержать
статическую библиотеку. Если кратко, то этот файл содержит внешние по отношению к программе
символы и инструкции как с этими символами поступать. Это может быть инструкция о связи
с динамически компонуемой библиотекой (DLL) или же инструкция вставки готового откомпилированного
кода, содержащегося в lib-файле. Qt стандартно распространяется в shared-версии, т.е.
откомпилированные программы требуют её DLL, поэтому почти все её lib-файлы - это просто
инструкции связи с DLL. Тем самым QtCore4.lib просто даёт компоновщику информацию о
том, что все перечисленные в ней символы нужно брать из QtCore4.dll.

Чтобы избавиться от зависимостей, Qt нужно пересобирать статически.


Ответ 2

Потому что эта lib не содержит нужного кода, а является прокладкой между вашим кодом
и dll. Ровно та же ситуация с lib для WinAPI.

Можно добавить библиотеки внутрь Jar файла?

Java проект использует сторонние библиотеки, подключаю их как maven зависимости через IDEA
При запуске сборки в target появляется собранный app.jar и папка lib с библиотеками. В манифесте эти библиотеки прописаны.
Можно ли запихнуть эти библиотеки внутрь моего app.jar?

Ответ

Вообще есть как минимум два плагина, который позволяют собрать jar файл с зависимостями.
Это Maven Shade plugin и Maven Assembly plugin. Как использовать каждый из этих плагинов можно найти по ссылкам на официальную документацию. Там же есть подробное описание когда, какой из них использовать (по мне они в большинстве случаем равнозначны, но иногда один из них подходит лучше).

Статическая библиотека: убрать зависимость от внутренних библиотек

Есть самописная библиотека С++ (.h и .cpp соответственно) использующая библиотеки OpenCV и boost. Заголовочный файл имеет вид: #include #include #include using namespace boost::numeric::ublas; и дальше объявления классов и функций (реализованных в cpp) Использую VS2010, если к проекту "напрямую" подкючать эту библиотеку, прописывать все необходимые файлы для работы openCV и boost, то все работает. Пробовал собрать статическую библиотеку lib. Подключаю заголовочный файл подключаю lib файл к новому проекту и компилятор ругается на неизвестные ему библиотеки: cv.h и тп... Как можно создать статическую библиотеку, так что бы человеку которому необходимо написать прогу с использованием самописной библиотеки, не надо было иметь собранные OpenCV и boost.

Ответ

boost::ublas — это header-only library, поэтому к вопросу она отношения не имеет. То есть тому, кто захочет использовать вашу штуковину, нужно будет иметь хэдеры boost'a, и в этом никакой проблемы лично я не вижу. Далее, правильное решение с OpenCV следующее — не нужно embedd'ить весь OpenCV в вашу библиотеку, а нужно поставлять библиотеку as is, а всех пользователей вашей библиотеки отправлять на opencv.org Решение с embedd'ингом плохое, поскольку вы лишаете пользователей вашей библиотеки возможности динамически линковаться с OpenCV и форсируете увеличение размера любого приложения, собранного с применением вашей библиотеки. Также embedd'инг всего OpenCV в вашу библиотеку чреват проблемами с безопасностью. Что должен сделать пользователь вашей библиотеки, в которую статически влинкован OpenCV 2.4.5, если он узнает, что в 2.4.5 нашли exploit, который позволяет получить доступ к любой системе? OpenCV, скажем, выпускает для этого патч-релиз 2.4.6, а ваш пользователь кусает локти. Последний пример, разумеется, сильно притянут за уши, но аргумент вполне себе имеет место быть. Если вы все-таки решите статически embedd'ить OpenCV в вашу библиотеку, то в Visual Studio это можно сделать, например, с помощью приложения LIB. Вам нужно взять файл вашей библиотеки и файл статически собранной библиотеки OpenCV, сдампить из них obj файлы и склеить эти файлы в новую библиотеку, которую и отправлять пользователю.

Как использовать LIB от другого компилятора?

Имеется LIB, собранная в BC3.1, она использует его RTL. Собственно, вопрос заключается в том, как воспользоваться этой библиотекой в другом компиляторе? Исходников библиотеки, понятное дело, нет. Есть ли способ собрать "добавку" в BC3.1 к этой библиотеке, которую потом спокойно использовать в другом компиляторе?

Ответ

Вам необходимо будет сделать библиотеку-прослойку. Поскольку исходная lib использует RTL, взаимодействовать с нею нужно только компилятором версии, в которой она была собрана. Соответственно, при помощи этого компилятора необходимо собрать новую библиотеку, которая будет клиентом к исходной, предоставлять интерфейс к функциональности исходной, и этот интерфейс должен удовлетворять ряду "переносимых" критериев: "Ansi C" интерфейс. Т.е. никаких экспорта классов, никакого экспорта STL и т.п.. Экспорт только функций, входные и выходные параметры только стандартные типы. Никаких include-ов стандартных библиотек. Если Вы сделаете один header, в идеале ему вообще не нужно содержать сторонних include-ов. Если содержит, в идеале это "Ansi C", как, например, "windows.h" (могу ошибаться, но, вроде бы, он без включений STL, классов и т.п.) Библиотека не будет бросать никакие exception. Все их от исходной необходимо обрабатывать, но не пробрасывать выше. Перехвать exception компиляторозависим. Вся память, выделяемая внутри библиотеки, должна освобождаться внутри библиотеки. Если где-то управление жизнью выделенной памяти передается клиенту, то интерфейсу надо иметь функцию, которая будет позволять освобождать такую память. Лучше отказаться от абстрактных структур. Теоретически это не должно быть проблемой, но многие детали реализации виртуализации не стандартизированы, а значит компиляторы могут выполнять их по-разному, и это на практике (у меня между MinGW и VS разных версий, хотя между разными компиляторами MinGW и между разными VS такой проблемы не наблюдал) приводит к проблемам. Вроде бы ничего не забыл.

Возможно ли подключить библиотеки .NET Framework в .NET Core 2.1.4?

Нужно подключить библиотеку в виде DLL, но у меня не получается. Возможно ли это?

Ответ

В общем случае нельзя. Например, потому, что .NET Core является подмножеством .NET Framework. Выход: перевести библиотеку на ту версию .NET Standard, которая поддерживает .NET Core.
Многие 3rd party библиотеки потихоньку обзаводятся соответствующии версиями.
Upd
Говорят еще, что если библиотека не содержит Windows-specific вызовов, то ее можно зареференсить прямо так. Но я не проверял. Какую библиотеку вы пытаетесь подключить и что именно у вас не получается?
P.S. Ну и заодно привяжу "обратный" вопрос: Использование Net.Core библиотек в Net.Framewok

Разница использования библиотек поддержки?

При чтении статей сталкиваюсь с тем, что пишут нужно подключить такую или такую библиотеку поддержки. Я немного почитал, чтоб постараться от сего зависит какую библиотеку нужно подключать.
Я так понял, что в зависимости для какого апи пишешь то такую библиотеку и нужно использовать.
Я открыл один из своих проектов и в градле заметил, что у меня бывает даже есть 2 библиотеки разных версий. Допустим так
android.support.v4 android.support.v13
Я так понимаю, что
android.support.v4
Можно вовсе удалить так как
android.support.v13
должна включать в себя все из предыдущей библиотеки, верно я понял?

Ответ

К сожалению все неправильно.
Во первых, версией библиотеки считается трехзначный номер в конце (как 24.3.0), а не число, что идет после v. в названии библиотеки. Эти числа - это до какого минимального API эта библиотека поддержки собственно оказывает поддержку. Так, v.4 значит, что библиотека поддержки будет работать на устройствах с API4 и выше.
Использовать нужно версию библиотеки не менее чем minSDKversion проекта и равную или более, чем compileSDKversion (targetSDKversion) а крайне желательно - последнюю стабильную (сейчас это 24.3.0), так как с каждой новой версией вносятся фиксы в существующие классы и дополняются новые классы или методы. При этом смотреть соответствие API нужно по мажорному номеру библиотеки (здесь 24.3.0 - для compileSDKversion API24).
Ознакомиться с изменениями, вносимыми в библиотеки поддержки с каждой новой ревизией можно на официальном сайте разработчика Android - здесь указано, какие именно изменения и дополнения были внесены с каждой ревизией и в какие именно из библиотек поддержки (так в ревизии 24.3.0 были внесены изменения в библиотеки v4, v7 (в подбиблиотеки AppCompat, MediaRouter, Preferences, RecyclerView) , Design
библиотеки support.v4 , support.v7 и тд - это разные библиотеки, с различными классами поддержки и выполняемыми функциями и они не взаимозаменяют друг друга по принципу большей версии. С полным списком библиотек поддержки Google и их назначением и функциями вы можете ознакомиться на все том же официальном сайте разработчика Android.
Например, библиотека com.android.support:support-v4:24.3.0 - библиотека поддержки с минимальным API, на котором она работает API4 и версией самой библиотеки - 24.3.0. Список классов и функций этой библиотеки можно посмотреть здесь. Как видите, это совсем не то же, что библиотека com.android.support:support-v7, в которую входит вообще несколько отдельных библиотек, как ApppCompat, CardView и тд.
PS: никакой библиотеки support.v21 у Google не наблюдается ..

Почему требуется QtCore.dll если уже есть QtCore.lib?

В проекте С++ (который компилируется в динамическую библиотеку) используется библиотека Qt, поэтому в Linker->Input добавлена статическая библиотека QtCore4.lib; почему во время использования проектной dll требуется также QtCore4.dll?

Ответ

Проблема состоит в том, что файл с расширением lib совершенно не обязан содержать статическую библиотеку. Если кратко, то этот файл содержит внешние по отношению к программе символы и инструкции как с этими символами поступать. Это может быть инструкция о связи с динамически компонуемой библиотекой (DLL) или же инструкция вставки готового откомпилированного кода, содержащегося в lib-файле. Qt стандартно распространяется в shared-версии, т.е. откомпилированные программы требуют её DLL, поэтому почти все её lib-файлы - это просто инструкции связи с DLL. Тем самым QtCore4.lib просто даёт компоновщику информацию о том, что все перечисленные в ней символы нужно брать из QtCore4.dll
Чтобы избавиться от зависимостей, Qt нужно пересобирать статически.