LINUX.ORG.RU

Вопросик по ld

 , ,


0

1

Собрал вот такую либу rtcConn.node

g++ -shared -pthread -rdynamic -m64 -z noexecstack -z relro -Wl,-soname=rtcConn.node -o Debug/obj.target/rtcConn.node -Wl,--start-group Debug/obj.target/rtcConn/addon.o Debug/obj.target/rtcConn/WebRtcConnection.o Debug/obj.target/rtcConn/ThreadPool.o Debug/obj.target/rtcConn/IOThreadPool.o Debug/obj.target/rtcConn/MediaStream.o Debug/obj.target/rtcConn/conn_handler/WoogeenHandler.o Debug/obj.target/rtcConn/erizo/src/erizo/DtlsTransport.o Debug/obj.target/rtcConn/erizo/src/erizo/IceConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/LibNiceConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/SdpInfo.o Debug/obj.target/rtcConn/erizo/src/erizo/SrtpChannel.o Debug/obj.target/rtcConn/erizo/src/erizo/Stats.o Debug/obj.target/rtcConn/erizo/src/erizo/StringUtil.o Debug/obj.target/rtcConn/erizo/src/erizo/WebRtcConnection.o Debug/obj.target/rtcConn/erizo/src/erizo/MediaStream.o Debug/obj.target/rtcConn/erizo/src/erizo/lib/LibNiceInterfaceImpl.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/IOThreadPool.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/IOWorker.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/Scheduler.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/ThreadPool.o Debug/obj.target/rtcConn/erizo/src/erizo/thread/Worker.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/PacketBufferService.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtcpForwarder.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtcpProcessorHandler.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtpUtils.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/QualityManager.o Debug/obj.target/rtcConn/erizo/src/erizo/rtp/RtpExtensionProcessor.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/DtlsSocket.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/DtlsClient.o Debug/obj.target/rtcConn/erizo/src/erizo/dtls/bf_dwrap.o Debug/obj.target/rtcConn/erizo/src/erizo/pipeline/Pipeline.o Debug/obj.target/rtcConn/erizo/src/erizo/stats/StatNode.o -Wl,--end-group -L/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib -lsrtp2 -lssl -ldl -lcrypto -llog4cxx -lboost_thread -lboost_system -lnice


Эти строчки указывают на то, что подключаемые библиотеки лежат в папке ...build/lib и нужно прилинковать либу ssl
-L/owt-server/source/agent/webrtc/rtcConn/../../../../build/libdeps/build/lib
-lssl


Я потом смотрю
ldd rtcConn.node
        linux-vdso.so.1 (0x00007fff90ff4000)
        libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4cbdf50000)
        libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f4cbda85000)
        liblog4cxx.so.10 => /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10 (0x00007f4cbd6bc000)
        libboost_thread.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1 (0x00007f4cbd497000)
        libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f4cbd292000)
        libnice.so.10 => not found
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4cbcf09000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4cbcb6b000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4cbc953000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4cbc734000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4cbc343000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4cbe549000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4cbc13f000)
        libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f4cbbf0a000)
        libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007f4cbbcdf000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4cbbad7000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f4cbb8d0000)
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4cbb698000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f4cbb466000)


и вижу что libssl берется вообще из /usr/lib/, хотя должно быть из ...build/lib. Почему так?

★★★★

Эти строчки указывают на то, что подключаемые библиотеки лежат в папке …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.

fsb4000 ★★★★★ ()
Ответ на: комментарий от fsb4000

Ух, точно, -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)



Почему в списке нет webrtc и прочих (log4cxx, ssl...) библиотек? Они же указаны при сборке. webrtc точно цепляется (rtcadapter.so вырастает до 70мб в связи с этим, без нее около 1mb). Такое ощущение что эти либы внедрились статически, хотя флага -static нет

gobot ★★★★ ()
Ответ на: комментарий от Harald

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

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

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

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

X512 ★★★ ()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от gobot

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

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

X512 ★★★ ()
Ответ на: комментарий от X512

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

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

то есть

.\test # запускается и работает есть папка .\libs рядом с бинарём
cd ..
.\folder_name\test # не запускается
fsb4000 ★★★★★ ()
Ответ на: комментарий от fsb4000

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

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

X512 ★★★ ()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

За этот 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

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

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 5)
Ответ на: комментарий от EXL

А как у 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.

X512 ★★★ ()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от EXL

-rpath=./lib/

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

X512 ★★★ ()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

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

  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. Ни одна не запустилась :)

fsb4000 ★★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)