Вопросик по ld

Эти строчки указывают на то, что подключаемые библиотеки лежат в папке …build/lib и нужно прилинковать либу ssl

-L/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib
-lssl

нет конечно.

Это лишь указывает что ты добавляешь папку /owt-server/source/agent/webrtc/rtcConn/../../../../build к путям в которых будет поиск библиотек, про то что нельзя использовать пути по умолчанию эти строчки ничего не говорят.

man ld

-L searchdir

Add path searchdir to the list of paths that ld will search for archive libraries and ld control scripts. You may use this option any number of times. The directories are searched in the order in which they are specified on the command line. Directories specified on the command line are searched before the default directories. All -L options apply to all -l options, regardless of the order in which the options appear. -L options do not affect how ld searches for a linker script unless -T option is specified.

If searchdir begins with «=», then the «=» will be replaced by the sysroot prefix, a path specified when the linker is configured.

The default set of paths searched (without being specified with -L) depends on which emulation mode ld is using, and in some cases also on how it was configured.

The paths can also be specified in a link script with the «SEARCH_DIR» command. Directories specified this way are searched at the point in which the linker script appears in the command line.

линкуй либо статически, либо используй rpath, либо запускай бинарник с переменной окружения LD_LIBRARY_PATH=/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib

А чем версия из дистра не устраивает?

Harald верно пишет. Попробуй rpath должно помочь.

Ух, точно, -L же просто добавляет путь к уже имеющимся!

Ещё по другой либе пожалуйста подскажите rtcadapter.so

g++ -shared -pthread -rdynamic -m64 -z noexecstack -z relro -Wl,-soname=rtcadapter.so -o Debug/obj.target/rtcadapter.so -Wl,--whole-archive ./Debug/obj.target/librtcadapter/../../../core/rtc_adapter/RtcAdapter.o ./Debug/obj.target/librtcadapter/../../../core/rtc_adapter/VideoReceiveAdapter.o ./Debug/obj.target/librtcadapter/../../../core/rtc_adapter/VideoSendAdapter.o ./Debug/obj.target/librtcadapter/../../../core/rtc_adapter/AudioSendAdapter.o ./Debug/obj.target/librtcadapter/../../../core/owt_base/SsrcGenerator.o ./Debug/obj.target/librtcadapter/../../../core/owt_base/AudioUtilitiesNew.o ./Debug/obj.target/librtcadapter/../../../core/owt_base/TaskRunnerPool.o -Wl,--no-whole-archive -L/owt-server/source/agent/webrtc/rtcFrame/../../../../build/libdeps/build/lib -lsrtp2 -lssl -ldl -lcrypto -llog4cxx -lboost_thread -lboost_system -lnice -L/owt-server/source/agent/webrtc/rtcFrame/../../../../third_party/webrtc-m79 -lwebrtc

ldd rtcadapter.so
        linux-vdso.so.1 (0x00007ffff598a000)
        libboost_thread.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1 (0x00007efff30d4000)
        libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007efff2ecf000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007efff2b31000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007efff2919000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007efff26fa000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efff2309000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efff3f93000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007efff2101000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007efff1d78000)

Да нет, все устраивает, со сборкой все нормально, я просто в целях познания хотел узнать почему так

либо используй rpath

За этот rpath надо убивать. В бинарниках не должно быть никаких абсолютных путей. Вычищал этот мусор в портах программ на Haiku.

либо запускай бинарник с переменной окружения LD_LIBRARY_PATH

+1. Можно скрипт запуска сделать.

В бинарниках не должно быть никаких абсолютных путей.

rpath может быть относительным, например ./libs

я просто в целях познания хотел узнать почему так

Флаг -L указывает на путь к библиотекам во время сборки, а не выполнения. Во время выполнения динамические библиотеки обычно загружаются по имени без указания пути. Место поиска библиотек зависит от конфигурации ОС и флагов динамического загрузчика вроде LD_LIBRARY_PATH.

rpath может быть относительным

Относительно чего? Рабочей директории или директории исполняемого файла?

а можно было вычистить мир от самой haiku, решив проблему на корню…

Относительно чего?

Сейчас проверил: относительно Рабочей директории.

то есть

.\test # запускается и работает есть папка .\libs рядом с бинарём
cd ..
.\folder_name\test # не запускается

Сейчас проверил: относительно Рабочей директории.

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

Есть $ORIGIN, позволяющий сделать относительно исполняемого файла, правда это не POSIX

За этот rpath надо убивать. В бинарниках не должно быть никаких абсолютных путей.

Разные задачи допускают разные решения

За этот rpath надо убивать. В бинарниках не должно быть никаких абсолютных путей. Вычищал этот мусор в портах программ на Haiku.

А как у Haiku реализована возможность подгрузки либ не через скрипт запуска, а через директорию lib? Типа как в Windows можно закинуть требуемую *.dll в директорию исп. файла и она подхватится, так и в Haiku можно рядом с исп. файлом создать директорию ./lib/ и кинуть туда требуемую либу.

Уж не через -rpath ли это сделано в дефолтном GCC, который проставляет -rpath=./lib/ каждому породжённому бинарнику?

P.S. я использовал подобное в порте Вангеров на Haiku:

https://github.com/haikuports/haikuports/blob/4169910522be2f706720f0b17f1361b6f5072711/games-arcade/vangers/vangers-1.0.0%7Egit.recipe#L118

Патченную разработчиками специально под игру эту либу никакого смысла пакетить отдельно не было.

А как у Haiku реализована возможность подгрузки либ не через скрипт запуска, а через директорию lib?

Это встроенное в систему поведение, система ищет динамические библиотеки в директории «lib» рядом с исполняемым файлом. Прописывание rpath не требуется. Ссылки на исходники: https://git.haiku-os.org/haiku/tree/src/system/runtime_loader/runtime_loader.cpp#n61, https://git.haiku-os.org/haiku/tree/headers/private/system/directories.h#n20, https://git.haiku-os.org/haiku/tree/src/system/runtime_loader/runtime_loader.cpp#n355.

Подобного дистрибьюторам различного софта остро не хватает в Linux, вот и приходится извращаться с rpath или скриптами запуска, порождающими тормозные bash-сеансы.

Как указал annulen, есть $ORIGIN. Если я правильно понимаю, можно прописать в rpath $ORIGIN/lib и получить поведение аналогичное Haiku. В Haiku $ORIGIN тоже поддерживается.

-rpath=./lib/

Так лучше не делать, не будет работать при запуске не из той рабочей директории, например при запуске из файлового менеджера. Ну или прописать установку рабочей директории в скрипте запуска, например cd `dirname "$0"`.

да $ORIGIN работает, но не для dynamic-linker :(

то есть свою glibc в папку lib не положить :(

https://stackoverflow.com/questions/54840445/relative-to-executable-path-to-ld-linux-dynamic-linker-interpreter

только shell script спасёт.

то есть свою glibc в папку lib не положить :(

А в этом есть необходимость? В glibc вроде бы стабильное ABI и обеспечивается обратная совместимость.

А в этом есть необходимость?

Ну тогда можно:

1. Cобирать проект на Manjaro/Arch Linux.

2. Сложить все либы в папку ./lib.

3. Создать архив

4. Скопировать архив на Ubuntu 12.04 LTS

5. Разархивировать и запустить и всё будет работать.

А без новой glibc не будет.

Теоретически можно:

1. Загрузиться в Ubuntu 12.04LTS

2. Подключить новый компилятор по ppa

3. Собрать все либы из исходников

4. Cобрать проект на Ubuntu 12.04LTS

5. Сложить все либы в папку ./lib.

6. И будет работать на всём что Ubuntu 12.04 LTS или новее

Но это будет занимать больше времени, и вряд ли кто так делает. Хотя и glibc мало кто локально таскает.

Я пробовал запускать несколько AppImage программ под Ubuntu 12.04. Ни одна не запустилась :)

За такое поведение нужно убивать. Помойка как в винде не нужна.

За такое поведение нужно убивать. Столько программ как в венде не нужно.

Поправил. Не благодари.

haiku

Столько программ как в венде

воображение over 9000