Приветствую. 

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

Библиотеки динамические (подключаемые во время выполнения программы)
Способ подключения библиотек 1 (не рабочий)

• 1. Относительный путь к библиотеке.

Способ подключения библиотек 2 (не рабочий, не находит библиотеки)

• 1. Имя библиотеки;
• 2. Для линковщика задается путь поиска библиотек.

Использую:
OS: Ubuntu
IDE: CodeBlock
Lang: C++

Добавлено через 10 минут и 30 секунд
Структура каталогов проекта:
bin
    debug (для всех нижеследующих проектов)
Project1
Project2

Добавь ключ компилятора -Wl,-rpath,.

я пробовал это значение указать в:

• Other Compiler options
• Other linker options

Но без результатов

Кхм. Попробуй в Other linker options вбить
 Если не сработает, значит что-то ты не так объяснил или я что-то не так поняла.

Спасибо за оказание помощи.
Я попробовал "-rpath .", но все так же без результатов.

Попробую объясниться иначе:
У меня два проекта. Один - динамическая библиотека, другой - консольное приложение. Оба проекта компилируют в одну директорию (относительно каждого из них, это ../bin/debug). Линковщику указую относительный путь к библиотеке (которая лежит в общем каталоге). Программа компилируется успешно, линкуется тоже. 
Но вот запуск прерывается из-за отсутствующей библиотеке по адресу "../bin/debug/lib.so", т.е. пути, который я задавал линковщику, относительно расположения файла проекта. 
Изменение адреса на имя для библиотеки, для линковщика, и добавление путей поиска (Search Directories -> Linker) все равно не дало возможности скомпилировать проект приложения - не находит библиотеки.

Это сообщение отредактировал(а) ivanstanislavovich - 1.9.2011, 19:38

Думаю это важно "-rpath ." не сработал, говорит, что не верный файл "."
Я убрал пробел и получил "-rpath." и проект скомпилировался.

Пропишите в переменную окружения LD_LIBRARY_PATH абсолютный путь к вашей .so до запуска самого приложения. Вариант с rpath тоже вполне рабочий, особенно если .so будет лежать в какой то фиксированной директории (лучше прямо из корня), иначе будут пляски с путями, если вы захотите перенести ваш исполняемый файл в другое место.

Или можно записать в rpath специальный символ:
 

xvr, спасибо за помощь. 
Но у меня не получилось.

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

1-й и 2-й (по отдельности для разных компиляций) по вашим рекомендациям, для разрешения вопроса
последние два, для разрешения других ошибок, связанных с ошибками:

и 


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

xvr, Вы говорили 
т.е. в это системная переменная ? Если так, то я этот способ пока не испытывал. Но я бы не хотел прибегать к решению проблемы таким вот способом. 

тут я нашел похоже решение. Но я не могу понять, что означает 

т.е. как-то добавить библиотеку, но не добавлять .so и некий lib. Что добавлять, и что такое lib (расширение файла?)

Читать.

Народ, а почему не работает "Search directories" для Linker:
Когда задаю только имя .so линковщик не находит библиотеку, хотя в директории поиска указан каталог, в котором есть эта библиотека?

Неужели никто не работает с динамическими библиотеками?! Как они у Вас подключаются?!

во первых - почему тема в общем разделе?
во вторых - ivanstanislavovich, в топике вы написали: Библиотеки динамические (подключаемые во время выполнения программы). так а зачем вы их тогда линкуете с приложением? используйте dlopen(), dlsym().
в третьих - это:

и это:

из-за того, что вы указываете не те пути для этих библиотек.
в четвертых - в чем все же у вас вопрос?

Добавлено через 3 минуты и 37 секунд
перечитал, и вроде как понял, что у вас проблема с тем, что исполняемый файл не находит .so`шки которые лежат в только вам известном "месте"(хм.. звучит-то как  ).
уже написали, это решается при помощи LD_LIBRARY_PATH.

Добавлено через 13 минут и 8 секунд

работаю.


dlopen(), dlsym().

boostcoder, Спасибо за ответ

По Вашим вопросам:

Перечитав предложенные группы тем я пришел к такому выводу. А по Вашему, где должна находится тема?

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

Ознакомлюсь, мне нужно время что бы понять, о чем Вы говорите.

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


Вопрос в том, что у меня имеется динамическая библиотека, которую я хочу подключить к приложению. Оба проекта (библиотека и приложения) компилируются в общую директорию (../bin/Debug, относительно обоих проектов). Испробовав множество различных способов, я получаю не верные ссылку к библиотеке на этапе линковки, или запуска приложения в режиме отладки, или самостоятельного запуска приложения. Искомый путь библиотек, при успешной компиляции и линковки приложения "../bin/Debug", относительно исполняемого файла, а мне необходимо получить "./", относительно исполняемого файла. 

Мне бы не хотелось использовать данный способ разрешения вопроса.

тут: C/C++: Программирование под Unix/Linux
но ладно. оставьте. модеры перенесут если что.


вам кажется?  


что касается линковки - для этого есть "-L" и "-rpath".
что касается поиска библиотеки при запуске - уже написали несколько раз - LD_LIBRARY_PATH. именно для подобных случаев она и предоставлена пользователю.


позвольте узнать о причинах?

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


Это сообщение отредактировал(а) boostcoder - 9.9.2011, 11:33

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

я использовал эти ключи, как мне кажется , во всех вариациях - положительного результата не получал:


Признаю свою не грамотность в незнании, когда нужно использовать `, а когда нет.

Считаю не правильным использовать системные пути для указания мест хранения библиотек приложения. К тому же уважаемый kemiisto предоставил ссылку, в которой объясняется почему этого делать не нужно, что совпадает с моим мнением.

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

Или в системную директорию, /usr/lib и т.п.

Это сообщение отредактировал(а) Леопольд - 9.9.2011, 12:02

это называется "приложение статически связанное с динамической библиотекой". т.е. библиотека-то динамическая. что позволяет вам заменять ее не пересобирая приложение, но без изменений экспортируемых сигнатур. другой способ - динамической связывание. реализуется при помощи dlopen() и dlsym(). в этом случае вам вовсе не нужно линковать библиотеку с приложением.


это не системные пути. эта переменная используется только в user-space. выполните в терминале: echo $LD_LIBRARY_PATH
что видите? правильно, ничего. потому что вы эту переменную никак не установили.
в добавок, LD_LIBRARY_PATH относится только к экземпляру bash`а, или сессии пользователя(если вы ее пропишите в ~/.bashrc). т.е. ее значение никак не отражается на системе и ее переменных.

Добавлено через 1 минуту и 9 секунд

это и в линуксе не работает, например ;)

Разве? Вроде бы работало... Хотя может и путаю, надо удостовериться, но мне негде сейчас. Под виндой точно работает)

Это сообщение отредактировал(а) Леопольд - 9.9.2011, 12:03

зато работает в венде. ибо поиск начинается именно с каталога в котором запущена программа.

ivanstanislavovich, кстати. почитайте еще про LD_PRELOAD.

Дайте полную строку линковки, как она записана у вас в файле.

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

объективных причин для этого я не нашел.

boostcoder, мне не нравится метод решения через $LD_LIBRARY_PATH. Выходит, для того что бы приложение работало, я должен прописывать пути к используемым библиотекам где-то на стороне. Но мне больше подходит решение, когда приложение самостоятельно ищет библиотеки в рабочей директории, как в Windows. Или это противоречит принципам Unix подобных ОС?
Насчет динамического и статического связывания - я более детально ознакомлюсь с динамическим связыванием и смогу общаться на эту тему. Но, как мне кажется, статическое связывание с динамической библиотекой, мне полностью подходит.

Не обязательно. Приложение может запускаться через shell'овский скрипт, который выставит LD_LIBRARY_PATH во что надо и запустит что надо.


В принципах 'Unix подобных ОС' делать shell'овские файлы по каждому поводу (и без повода)   

xvr, у меня нет рабочей комбинации, по этому я не знаю какую из них предоставить Вам. 
В одних случаях, я получаю ошибку "undefined reference" к используемым функциям в библиотеке. В других - cannot find -[имя библиотеки].so. Если задать Link libraries не имя, а путь к библиотеке - компиляция проходит успешно, но приложение не запускается, ни в отладке, ни самостоятельно из-за не правильного пути к библиотеке (описано выше)
Если подставить библиотеки по "горбатому" пути - приложение работает.

Это сообщение отредактировал(а) ivanstanislavovich - 9.9.2011, 12:19

эм..
а так, не пробовали?



угу. для библиотек есть стандартные каталоги "/lib, /usr/lib, /usr/local/lib"

Давайте все нерабочие

xvr, хорошо:







.................................................. пх-х-х

Добавлено через 4 минуты и 56 секунд
boostcoder, я пробую LD_LIBRARY_PATH, по Вашим рекомендациям


Но Code::Block по прежнему не находит библиотеку  (C::B перезапустил). В чем может быть причина ?

Последняя явно неправильно - обратные кавычки обозначают совсем другое 
Все первые ругались не на rpath а на ваш -l Видимо там было написан -lLib.so, это неправильно. При такой записи файл с библиотекой должен называться libLib.so.so 

xvr, я не понял Вас.

-l  о каком моем этаком Вы говорите?
там было написан  это где Это там ?

Имя моей библиотеки имело такие имена, я эксперементировал:


во всех случаях я имел ошибку "cannot find", за исключением того, что если имя библиотеки было "liblib" то "cannot find -|lib.so" ошибку имел.

Не моглибы Вы, xvr, предоставить мне информацию о "`"?

Это сообщение отредактировал(а) ivanstanislavovich - 10.9.2011, 12:13

если ваша библиотека зовется liblib.so, то опцию нужно указывать так: -llib
если бы ваша библиотека звалась libmy.so, то опцию нужно указывать так: -lmy

Добавлено @ 12:25
т.е. вне зависимости от типа библиотеки(.a/.so) расширение указывать не нужно.
второе - библиотеки должны иметь префикс "lib". но при указании их линковщику, префикс указывать не нужно.

Это сообщение отредактировал(а) boostcoder - 10.9.2011, 12:26

xvr, 
boostcoder, 
Спасибо Вам! Примного благодарен. Вашими советами!

Выходит так, нужно делать:
библиотеку называть с префиксом lib, но обращаться к ней без него, и без расширения (so, a). 
я же совершал сразу все ошибки, по не знанию
еще нужно в опциях линковщику задать "-Wl,-rpath=.", для того, что бы приложение искало библиотеки в своем корневом каталоге.

Недели возни и все из-за таких мелочей. Почему этого нет в мануалах? Я там находил как подключать библиотеки, но таких нюансов не было

Добавлено через 1 минуту и 13 секунд
newbee, 
kemiisto, 
Леопольд, 
Так же спасибо!

эм.. не помню что там есть... давно не читал.

Это не мелочи. Это ублюдочно-тошнорвотная сишечная модель компиляции-линковки из прошлого тысячелетия.


Есть. А то откуда же люди знают?

Дайте полную командную строку линковки. Очень трудно догадаться что там не так не видя этого самого 'там'   


Это стандартная фича шела (да и make'а тоже). Строка внутри `` трактуется как команда, которая выполняется. То, что она выведет в стандартный поток вывода и будет использовано вместо всей конструкции ``
Например -
найдет g++ на путях поиска и выведет полную информацию о файле
У меня (под cygwin'ом) это дает

xvr, Спасибо Вам. Не беспокойтесь более об этом - вопрос уже разрешен. И спасибо за информацию о "`"