Подключение статической библиотеки, которая сама в себя включает другую статическую библиотеку

@~~Aston Martin~~ · 11.03.2015, 17:15. **Показов** 5952. **Ответов** 11

Author24 — интернет-сервис помощи студентам

Есть проект с подпроектами в QtCreator.
Допустим есть три проекта:
1. Статическая библиотека A
2. Статическая библиотека B, которая подключает библиотеку А и работает с ней внутри себя
3. Тестовый проэктик С, который подключает статическую библиотеку B и хочет ей пользоваться, ничего не зная о статической библиотеки А.

Так вот, в проекте C в про файле:

C++ (Qt)

unix|win32: LIBS += -L$$OUT_PWD/../../Network/NetworkMessenger/MessengerServer/ -lMessengerServer
 
INCLUDEPATH += $$PWD/../../B
DEPENDPATH += $$PWD/../../B
 
win32:!win32-g++: PRE_TARGETDEPS += $$OUT_PWD/../../B.lib
else:unix|win32-g++: PRE_TARGETDEPS += $$OUT_PWD/../../B.a

(всё условно)

Значит пишу я в тестовом проекте:

C++

1	#include "B.h"

В этом файле есть указатели на класса из А (допустим А* а

, но я тактично сделал форвард декларейшен классов и приинклюлдил их уже в B.cpp. (так бы он не нашёл файлы инклюда проекта А как не странно)

Теперь мне пишет про unresolved externals, причём символы из проекта А, которые напрямую я никак не использую в своей тестилке - "С". В "C" я вызываю функцию библиотеки "B", которую я честно подключил к C. Внутри этой функции используется уже библиотека "A", но снаружи я этого в "C" не вижу.

В общем сборка проекта С выдаёт ошибки неразрешённых внешних символов. Если к проекту С подключить и библиотеку A, тогда да - всё прекрасно собирается, но чёрт возьми, не должен же я следить за тем, что использует та или иная библиотека, я по идее должен просто её использовать, а если она что - то там и использует, поскольку она статическая, она должна в себя втянуть вкомпильнуть свои зависимости ...

Как правильно подключать только библиотеку B, чтоб не требовалось так же подключить и библиотеку А, которую я напрямую не использую, использует её только сама библиотека B

Добавлено через 20 минут
Я думаю тут вопрос в том, как статический влинковать при сборке мою статическую библиотеку А в статическую библиотеку B, чтоб при использование B в C у меня не спрашивало бы про A.

Добавлено через 1 час 24 минуты
Переделал статические библиотеки А и B в динамические, теперь всё собралось но крэшится при запуске из QtCreator, очевидно, что требует эти две библиотеки рядом с тестилкой С. В общем те же яйца, только в профиль

Я так понял, что б это всё заработало, следует собирать B статический, чтоб в неё полностью вкомпильнулась А.
Но, не нарушает ли это лицензий Qt ? Как это сделать ?

@~~Aston Martin~~ · 11.03.2015, 20:28 **[ТС]**

Народ, ну помогите же новичку

Вот архив с тестовым проектом из трёх проектов:
A, B и Tester.
Цель: Собрать Tester, не подключая к нему библиотеку А. К нему подключена только B (к которой в своё время подключена А)

@Avazart · 11.03.2015, 22:44

А зачем тебе сдались статические библиотеки от них проку то мало...

@~~Aston Martin~~ · 11.03.2015, 22:51 **[ТС]**

Сообщение от Avazart

А зачем тебе сдались статические библиотеки от них проку то мало...

На самом особой роли не играет, можно делать и динамическими, но опять же, если я к своему приложению Tester подключаю библиотеку B (которая внутри подключает А), то проект то соберётся, но не запуститься, т.к. рядом пусковым файлом должна будет так же лежать библиотека А, о которой я как бы ничего не знаю. Может бы быть хрен знает сколько зависимостей у подключаемых DLL-к ... и что, их все вручную искать и копировать в папку с проектом ?

P.S.: статические делаю в том случае, когда это какой - нибуть важный код ядра и без него программа собираться не должна - чисто для удобства.

@Avazart · 11.03.2015, 22:59

Сообщение от Aston Martin

. и что, их все вручную искать и копировать в папку с проектом ?

Именно так.

Программа для сборки DLL-лок для переноса Qt-приложений

@andrejap · 11.03.2015, 23:08

* Ты подключал средствами QtC A в B ? Или сам это набирал:
else:unix|win32-g++: PRE_TARGETDEPS += $$OUT_PWD/../../B.a ?
* Хедеры подключал которые требуется?
* То, что ты писал насчет C требуется и для B:
INCLUDEPATH += $$PWD/../../A (в про-файле для B)
* Кроме этого ты должен сначала собирать A, затем B, а затем уж C.

Советы капитановкие, но все же.

@~~Aston Martin~~ · 11.03.2015, 23:57 **[ТС]**

Сообщение от Avazart

Именно так.

Это всё понятно, но это ж не qt-шная библиотека, а моя
Неужели нет способа подключить библиотеку B, которая внутри себя использует библиотеку А, к пусковому проекту С так, чтоб не подключать и B и А, а просто подключить B. Так по идее должно быть исходя из здравого смысла. То есть меня не должно волновать, что внутри себя использует статическая библиотека B, пусть хоть 100 других, мне должно быть достаточно просто её подключить, а все её зависимости должны автоматом прилинковываться. (это описание здравого смысла)

Сообщение от andrejap

Ты подключал средствами QtC A в B ?

да

Сообщение от andrejap

Хедеры подключал которые требуется?

они то тут причём, что надо - подключил.

Сообщение от andrejap

Кроме этого ты должен сначала собирать A, затем B, а затем уж C.

ну ты уж меня совсем ха дятла не держи

Открой архив из поста номер 2 и посмотрим в чём дело

@vvic · 12.03.2015, 11:12

В архиве с кодом если в b.pro закоментить строки с линковкой (т.е. где LIB+=) то b.pro собирается!
Т.е. при сборке b.lib совсем даже не понадобилась a.lib ... что поясняет зачем требуется a.lib при построении tester.exe.
Теперь осталось понять как сделать чтобы надобилось ... если такое вообще возможно. Вероятно надо искать что-то в ключах не компилятора но сборщикак библиотек (линковщика) т.к. именно его не волнует что для сборки b.lib нету а.lib (не очевидно что у него вообще есть режим такой заботы)

@~~Aston Martin~~ · 12.03.2015, 11:45 **[ТС]**

Сообщение от vvic

В архиве с кодом если в b.pro закоментить строки с линковкой (т.е. где LIB+=) то b.pro собирается!

Какая проницательность

Если отключить подключение библиотеки, конечно она не будет требоваться

На самом деле B и так соберётся, не соберётся Tester, к которому подключена B, к которой подключена A. Соберётся только если напрямую подключить А к Tester в дополнение к B.

По поводу ключей компилятора ... Тут ключи линковщика в данном случае нужны, но думаю это не поможет. Скорее всего нужно статический собирать B, чтоб в неё вшилась А, а это уже статическая сборка самого Qt и нарушение comunity лицензий.

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

@vvic · 12.03.2015, 15:48

>Какая проницательность. Если отключить подключение библиотеки, конечно она не будет требоваться
Нуу ... вы чего наезжаете?
Удаляется возможность найти библиотеку а ... и через это тестируется что она и не используется (т.к. сборщик библиотеки не ругается) ... значит сборщику библиотеки b походу не нужна библиотека a.

У автора вопроса ожидания определенного поведения от сборщика библиотек как раз основано на том что при формировании библиотеки b из a будет прилинковываться все что надо для функций b ... так что полагаю что мое замечание по делу.

> Скорее всего нужно статический собирать B, чтоб в неё вшилась А
И чего такого нестатического написано в pro-файлах?

Добавлено через 15 минут
>а это уже статическая сборка самого Qt
Интересно как вы пришли к такому выводу?

@~~Aston Martin~~ · 12.03.2015, 17:36 **[ТС]**

Сообщение от vvic

Нуу ... вы чего наезжаете?

Да ты чЯго, я пацифист

Сообщение от vvic

Удаляется возможность найти библиотеку а ... и через это тестируется что она и не используется (т.к. сборщик библиотеки не ругается) ... значит сборщику библиотеки b походу не нужна библиотека a.

Посмотри на файл B.cpp библиотеки B:

C++

#include "b.h"
#include "a.h"
 
B::B()
{
    A* a = new A;
}

Видишь? Класс из библиотеки А там используется, значит по мимо того, что приинклюжен её хэдэр:

C++

1	#include "a.h"

нужна ещё и реализация того, что в этом хэдэре

Даже в этом убогом примере библиотеке B нужно знать, как реализован конструктор и деструктор класса А из библиотеки А, по этому библиотека А и подключается к B и убрать подключение не получится

Сообщение от vvic

У автора вопроса ожидания определенного поведения от сборщика библиотек как раз основано на том что при формировании библиотеки b из a будет прилинковываться все что надо для функций b ... так что полагаю что мое замечание по делу.

В чём смысл замечания я так и не понял

Сообщение от vvic

И чего такого нестатического написано в pro-файлах?

ват ?

Сообщение от vvic

Интересно как вы пришли к такому выводу?

Ну как как, из чтения доков. Если ты хочешь статический линковать свой проект, то тебе нужна статическая сборка Qt.
Хотя вот тут то как раз и кроется подвох. Дело в том, что статический Qt нужен для линковки проекта вместе с либами самого Qt, а вот для линковки одной своей либы статический в комплекте со своей же другой либой, чтоб на нашем примере А влинковалась бы в B, во тут уже хз, нужна статическая сборка самого Qt или есть ход конём ?

@vvic · 12.03.2015, 19:31

>Даже в этом убогом примере библиотеке B нужно знать, как реализован конструктор и деструктор класса А
>из библиотеки А, по этому библиотека А и подключается к B и убрать подключение не получится
Вот вы и поняли в чем заключается как вы сказали "проницательность" того я описал в своем первом сообщении

>В чём смысл замечания я так и не понял
Ну жаль ... может вы недопоняли то что я написал в первом посте и потому и пишите всякие там "Какая проницательность"

>ват ?
Посмотрите к какой вашей фразе был задан вопрос ... или снова вам не ясно

>во тут уже хз, нужна статическая сборка самого Qt или есть ход конём ?
Поздравляю ... вы поняли что ваша рекомендация о статической сборки Qt сомнительна.

На сим предлагаю закончить терки ... если есть что по исходному вопросу то пишите. Критикой моего поста вы к решению вопроса ничего не добавляете.

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	11.03.2015, 22:44	3
	А зачем тебе сдались статические библиотеки от них проку то мало... 1

@~~Aston Martin~~ Заблокирован
	11.03.2015, 22:51 [ТС]	4
	Сообщение от Avazart А зачем тебе сдались статические библиотеки от них проку то мало... На самом особой роли не играет, можно делать и динамическими, но опять же, если я к своему приложению Tester подключаю библиотеку B (которая внутри подключает А), то проект то соберётся, но не запуститься, т.к. рядом пусковым файлом должна будет так же лежать библиотека А, о которой я как бы ничего не знаю. Может бы быть хрен знает сколько зависимостей у подключаемых DLL-к ... и что, их все вручную искать и копировать в папку с проектом ? P.S.: статические делаю в том случае, когда это какой - нибуть важный код ядра и без него программа собираться не должна - чисто для удобства. 0

@Avazart 8385 / 6147 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	11.03.2015, 22:59	5
	Сообщение от Aston Martin . и что, их все вручную искать и копировать в папку с проектом ? Именно так. Программа для сборки DLL-лок для переноса Qt-приложений 0

@andrejap 13 / 13 / 7 Регистрация: 21.04.2013 Сообщений: 245
	11.03.2015, 23:08	6
	* Ты подключал средствами QtC A в B ? Или сам это набирал: else:unix\|win32-g++: PRE_TARGETDEPS += $$OUT_PWD/../../B.a ? * Хедеры подключал которые требуется? * То, что ты писал насчет C требуется и для B: INCLUDEPATH += $$PWD/../../A (в про-файле для B) * Кроме этого ты должен сначала собирать A, затем B, а затем уж C. Советы капитановкие, но все же. 0

@~~Aston Martin~~ Заблокирован
	11.03.2015, 23:57 [ТС]	7
	Сообщение от Avazart Именно так. Это всё понятно, но это ж не qt-шная библиотека, а моя Неужели нет способа подключить библиотеку B, которая внутри себя использует библиотеку А, к пусковому проекту С так, чтоб не подключать и B и А, а просто подключить B. Так по идее должно быть исходя из здравого смысла. То есть меня не должно волновать, что внутри себя использует статическая библиотека B, пусть хоть 100 других, мне должно быть достаточно просто её подключить, а все её зависимости должны автоматом прилинковываться. (это описание здравого смысла) Сообщение от andrejap Ты подключал средствами QtC A в B ? да Сообщение от andrejap Хедеры подключал которые требуется? они то тут причём, что надо - подключил. Сообщение от andrejap Кроме этого ты должен сначала собирать A, затем B, а затем уж C. ну ты уж меня совсем ха дятла не держи Открой архив из поста номер 2 и посмотрим в чём дело 0

@vvic 0 / 0 / 0 Регистрация: 22.02.2015 Сообщений: 3
	12.03.2015, 11:12	8
	В архиве с кодом если в b.pro закоментить строки с линковкой (т.е. где LIB+=) то b.pro собирается! Т.е. при сборке b.lib совсем даже не понадобилась a.lib ... что поясняет зачем требуется a.lib при построении tester.exe. Теперь осталось понять как сделать чтобы надобилось ... если такое вообще возможно. Вероятно надо искать что-то в ключах не компилятора но сборщикак библиотек (линковщика) т.к. именно его не волнует что для сборки b.lib нету а.lib (не очевидно что у него вообще есть режим такой заботы) 0

@~~Aston Martin~~ Заблокирован
	12.03.2015, 11:45 [ТС]	9
	Сообщение от vvic В архиве с кодом если в b.pro закоментить строки с линковкой (т.е. где LIB+=) то b.pro собирается! Какая проницательность Если отключить подключение библиотеки, конечно она не будет требоваться На самом деле B и так соберётся, не соберётся Tester, к которому подключена B, к которой подключена A. Соберётся только если напрямую подключить А к Tester в дополнение к B. По поводу ключей компилятора ... Тут ключи линковщика в данном случае нужны, но думаю это не поможет. Скорее всего нужно статический собирать B, чтоб в неё вшилась А, а это уже статическая сборка самого Qt и нарушение comunity лицензий. Хотя...может и есть какой то ключ, который бы не явно зависимые библиотеки подключал, по крайней мере хотелось бы на это надеется 0

@vvic 0 / 0 / 0 Регистрация: 22.02.2015 Сообщений: 3
	12.03.2015, 15:48	10
	>Какая проницательность. Если отключить подключение библиотеки, конечно она не будет требоваться Нуу ... вы чего наезжаете? Удаляется возможность найти библиотеку а ... и через это тестируется что она и не используется (т.к. сборщик библиотеки не ругается) ... значит сборщику библиотеки b походу не нужна библиотека a. У автора вопроса ожидания определенного поведения от сборщика библиотек как раз основано на том что при формировании библиотеки b из a будет прилинковываться все что надо для функций b ... так что полагаю что мое замечание по делу. > Скорее всего нужно статический собирать B, чтоб в неё вшилась А И чего такого нестатического написано в pro-файлах? Добавлено через 15 минут >а это уже статическая сборка самого Qt Интересно как вы пришли к такому выводу? 0

@vvic 0 / 0 / 0 Регистрация: 22.02.2015 Сообщений: 3
	12.03.2015, 19:31	12
	>Даже в этом убогом примере библиотеке B нужно знать, как реализован конструктор и деструктор класса А >из библиотеки А, по этому библиотека А и подключается к B и убрать подключение не получится Вот вы и поняли в чем заключается как вы сказали "проницательность" того я описал в своем первом сообщении >В чём смысл замечания я так и не понял Ну жаль ... может вы недопоняли то что я написал в первом посте и потому и пишите всякие там "Какая проницательность" >ват ? Посмотрите к какой вашей фразе был задан вопрос ... или снова вам не ясно >во тут уже хз, нужна статическая сборка самого Qt или есть ход конём ? Поздравляю ... вы поняли что ваша рекомендация о статической сборки Qt сомнительна. На сим предлагаю закончить терки ... если есть что по исходному вопросу то пишите. Критикой моего поста вы к решению вопроса ничего не добавляете. 0