Последовательное динамическое связывание библиотек

[andrew.k]

Во вложении тестовый проект. Проверял на линуксе.
У нас имеется библиотека core, которая собирается в динамическую libcore.so.
Далее вторая библиотека main, которая использует и динамически линкуется с libcore.so, и в свою очередь собирается в libmain.so.

Теперь у нас есть программа app. Которая использует libmain.so динамически.
Все это организовано в проект subdirs и отказывается собираться.

При сборке подпроекта app, получаются следующие сообщения об ошибке:

Код

Bash
/usr/bin/ld: warning: libcore.so.1, needed by ../bin/libmain.so, not found (try using -rpath or -rpath-link)
 

Хотя libcore.so успешно собрано и лежит рядом с libmain.so

Решается это двумя некрасивыми способами.

1. Слинковать дополнительно app с libcore (ключ -lcore).
Тогда все успешно собирается, при этом app становится слинкован с libcore.
Но это странное желание компилятора. Если библиотек много и много зависимостей, что их все высматривать и линковать в конечном приложении?

2. Собранную библиотеку libcore.so положить в системную директорию, например, /usr/lib
Тогда все успешно собирается, как и требовалось.
При этом после сборки, из системного пути библиотеку можно удалить.

И приложение успешно запускается из папки сборки.

Код

Bash
LD_LIBRARY_PATH=`pwd` ./app

То есть принципиально такая схема работает, но компилятор что-то не догоняет либо я.

Поэтому вопросы.

1. В чем принципиальная разница между этими схемами линковки библиотек?
2. Что мешает компилятору собрать проект без помещения библиотеки в системную директорию.
3. что такое -rpath и -rpath-link? как это может помочь и как это использовать?
gcc ругается, что такого ключа не знает.

[andrew.k]

Неужели совсем специалистов нет? 

[Old]

Добавьте в pro файл app:
QMAKE_RPATHDIR = ../bin
и все будет хорошо.

В linux линкер, так же как и загрузчик, ищет библиотеки в определенных местах. ../bin в эти места не входит, поэтому ему нужно помочь.

[qate]

2. Что мешает компилятору собрать проект без помещения библиотеки в системную директорию.
3. что такое -rpath и -rpath-link? как это может помочь и как это использовать?
gcc ругается, что такого ключа не знает.

2. Линкер не знает где искать, ему надо помочь: QMAKE_LFLAGS += -L/where/is/Lib/now
3. Опция линкера: -Wl,-rpath,/where/is/Lib/now/will/be

rpath будет удобен при отладке на машине девелопера т.к. либу он найдет, но на другой машине такого пути не будет, поэтому надо запускать через LD_LIBRARY_PATH=/where/is/Lib/now ./app

[andrew.k]

Добавьте в pro файл app:
QMAKE_RPATHDIR = ../bin
и все будет хорошо.

В linux линкер, так же как и загрузчик, ищет библиотеки в определенных местах. ../bin в эти места не входит, поэтому ему нужно помочь.

Че-то это не помогло совсем.

[Old]

Че-то это не помогло совсем.

Странно.
А что пишет?

[andrew.k]

2. Что мешает компилятору собрать проект без помещения библиотеки в системную директорию.
3. что такое -rpath и -rpath-link? как это может помочь и как это использовать?
gcc ругается, что такого ключа не знает.

2. Линкер не знает где искать, ему надо помочь: QMAKE_LFLAGS += -L/where/is/Lib/now

Если внимательно прочитать описание проблемы, то там описано, что линкер не видит только одну из двух либ, которые лежат в одной и той же директории.
При этом он ее не видит в том случае, когда ликовать ее не требуется.
А когда добавляешь -lmain сразу чудесным образом видит.

Отсюда понятно, что проблема не в этом.

3. Опция линкера: -Wl,-rpath,/where/is/Lib/now/will/be

Ничего из этого не помогло.

добавил

Код

C++ (Qt)
QMAKE_LFLAGS += -rpath

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

[andrew.k]

Че-то это не помогло совсем.

Странно.
А что пишет?

Помогло, если собирать без Shadow Build.
Только опять же это не совсем то, что нужно.
В этом случае бинарник app слинковался с либой по прямому пути.
Поэтому для нормального релиза все равно придется собирать по-другому. Как описано выше.

[Old]

А попробуйте эти переменные:
QMAKE_LFLAGS_RPATH
QMAKE_LFLAGS_RPATHLINK