LINUX.ORG.RU
← wget парсинг почты yandex
FPDF и буфер обмена →

из кучи *.o

Например, обычно LD используется для линковки стандартных объектных файлов Юникса на стандартной Юникс системе. На такой системе для линковки файла hello.o в запускаемый файл достачно набрать следующую команду: ld -o <имя-выходного-файла> /lib/crt0.o hello.o -lc

http://www.opennet.ru/docs/RUS/gnu_ld/gnuld-2.html

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

Из какой конкретно библиотеки ты не можешь посмотреть зависимости?

libgbd.a из собранного gdb_7.5.1 При использовании этой либы получаются такие ошибки 

/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:15880: undefined reference to `get_DW_FORM_name'
/usr/local/lib/libgdb.a(dwarf2read.o): In function `dwarf_tag_name':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:15844: undefined reference to `get_DW_TAG_name'
/usr/local/lib/libgdb.a(dwarf2read.o): In function `decode_locdesc':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:16694: undefined reference to `get_DW_OP_name'
/usr/local/lib/libgdb.a(dwarf2read.o): In function `dwarf_attr_name':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:15867: undefined reference to `get_DW_AT_name'
/usr/local/lib/libgdb.a(dwarf2read.o): In function `dwarf_type_encoding_name':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:15902: undefined reference to `get_DW_ATE_name'
/usr/local/lib/libgdb.a(dwarf2read.o): In function `dwarf_attr_name':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2read.c:15867: undefined reference to `get_DW_AT_name'
/usr/local/lib/libgdb.a(dwarf2loc.o): In function `unimplemented':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2loc.c:2485: undefined reference to `get_DW_OP_name'
/usr/local/lib/libgdb.a(dwarf2loc.o): In function `disassemble_dwarf_expression':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2loc.c:3480: undefined reference to `get_DW_OP_name'
/usr/local/lib/libgdb.a(dwarf2loc.o): In function `dwarf2_compile_expr_to_ax':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/dwarf2loc.c:2932: undefined reference to `get_DW_OP_name'
/usr/local/lib/libgdb.a(symtab.o): In function `create_filename_seen_cache':
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/symtab.c:3124: undefined reference to `filename_eq'
/home/qwerty/hjgfg/zzz/gdb/7.5.1/gdb-7.5.1/gdb/symtab.c:3124: undefined reference to `filename_hash'
Просто, «угадай мелодию» - какой либы не хватает при сборке.

Napilnik ★★★★★
() автор топика

.a это архив .o-файлов, который можно распаковать командой ar. Слинковать их в .so можно. Только информация о зависимостях .so-файла указыватся в виде флагов линкера при линковке, зачем тебе их потом смотреть утилитой ldd, если ты сам их укажешь при вызове линкера?

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

Хороший способ но тут не получится. Вылезает куча ошибок типа 

gdb-7.5.1/gdb/top.c:1424: undefined reference to `history_base'
Саму разделяемую библиотеку пытался собрать только для борьбы с неопределёнными ссылками а здесь их ещё больше.

Napilnik ★★★★★
() автор топика

Зависимости при сборке динамической библиотеки ты будешь все равно вручную прописывать.

anonymous
()

a файлы самодостаточны в них не извлечь зависимости к внешним dynamic so, уже твой конкретный бинарник или shared so должны быть слинковаными со всеми зависимостями необходимыми внутренней static a.

objdump -af libstatic.a

/usr/bin/c++ -fPIC -shared -Wl,-soname, libshared.so.25 -o /output/libshared.so.25 functiondatetime.cpp.o -Llibs libs/libstatic1.a libs/libstatic2.a -lz -lXss -lX11 -Wl

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

Значит остаётся только пробовать накормить собираемый бинарник зависимостями полученными при ldd gdb. В принципе, у libgdb.a должны быть те же зависимости что и у gdb.

$ ldd gdb
        linux-vdso.so.1 =>  (0x00007ffff6dff000)
        /usr/lib64/freetype-infinality/libfreetype.so.6 (0x000000359f400000)
        /usr/lib64/cairo-freeworld/libcairo.so.2 (0x00000035abe00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x000000359a000000)
        libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00000035a8e00000)
        libz.so.1 => /lib64/libz.so.1 (0x000000359ac00000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003599c00000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x000000359f000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003599800000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000359a400000)
        libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00000035aae00000)
        libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x000000359f800000)
        libpng15.so.15 => /lib64/libpng15.so.15 (0x000000359e800000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x000000359fc00000)
        libX11.so.6 => /lib64/libX11.so.6 (0x000000359b800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003599400000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x000000359bc00000)
        libXau.so.6 => /lib64/libXau.so.6 (0x000000359c000000)

linux-vdso.so.1 - похоже на модуль ядра и путь к ней не указан, странная библиотека.

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

И не в падлу тебе так через жопу все делать? Что мешает посмотреть в makefile, как конкретно gdb линкуется?

anonymous
()

http://habrahabr.ru/post/150327/

1. Содержимое статической библиотеки можно посмотреть и без создания динамической.

2. Возможно, у тебя библиотеки идут не в том порядке.

3. Возможно, в новой версии какой-то библиотеки не стало этих символов (с которыми происходит линковка).

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

А, так да, линкеру все завмсимости нужно отдавать.

Бгг)

find /usr/lib/ -iname "*.so" -type f -print | xargs nm -A -D | grep "get_DW_FORM_name"
Kuzz ★★★
()
Последнее исправление: Kuzz (всего исправлений: 2)
Ответ на: комментарий от anonymous

И не в падлу тебе так через жопу все делать? Что мешает посмотреть в makefile, как конкретно gdb линкуется?

Если ldd это через жопу то makefile - сериал 346 килобайт анала лье под водой.

Napilnik ★★★★★
() автор топика

можно ли из неё собрать *.so чтобы посмотреть зависимости утилитой ldd?

Твой вопрос некорректен. Зависимости, показываемые ldd, определяются исключительно командой линкера, которой собирается *.so, т.е. что слинкуешь, то и будет показывать.

annulen ★★★★★
()

этот клован уже в dev добрался? лор не торт

anonymous
()

Имеется статическая библиотека *.a можно ли из неё собрать *.so чтобы посмотреть зависимости утилитой ldd? Или, если невозможно, собрать *.so из кучи *.o для той же цели.

Нет и нет. .o должны были собираться с -fPIC

amphibrakhij
()
Ответ на: комментарий от Legioner

.a это архив .o-файлов, который можно распаковать командой ar. Слинковать их в .so можно.

Ну-ну. Попробуй

amphibrakhij
()
Ответ на: комментарий от Legioner

А как примерно заставить сборочную систему вместо исполняемого файла gdb собрать libgdb.so?

Napilnik ★★★★★
() автор топика

Блин, ну палево же:)

Napilnik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← wget парсинг почты yandex
Development
FPDF и буфер обмена →