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

Используя цепочку инструментов для кросс-компиляции, предоставленную поставщиком (очевидно, производную от OpenEmbedded), я не могу встроить абсолютный путь к сторонним (с открытым исходным кодом, скомпилированным в доме) библиотекам. Со следующей командной строкой gcc:

arm-linux-gcc test_connect_send.o gprs_connect.o \
    /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so \
    /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so \
    /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so \
    /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so \
    /package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so \
    /package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0  -o test_connect_send

objdump говорит:

Dynamic Section:
  NEEDED      /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgprs_stuff.so
  NEEDED      /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libpower_supply_stuff.so
  NEEDED      /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libgsm_stuff.so
  NEEDED      /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/libtcp_stuff.so
  NEEDED      libvortex-1.1.so.0
  NEEDED      libaxl.so.0
  NEEDED      libgcc_s.so.1
  NEEDED      libc.so.6

Обратите внимание, что у библиотек моего поставщика есть полный путь, а у aspl — нет. Также обратите внимание, как встроенное имя отличается от того, которое я указал в командной строке. Я хотел бы знать, почему (кто возится с моими путями), и как это решить.

p.s.: я знаю о RPATH, это не тот ответ, который я ищу


c cross-compiling gnu-toolchain
person Community    schedule 14.07.2009    source источник
comment
Есть ли в вашем компиляторе gcc флаг -print-file-name? Попробуйте это: arm-gcc-linux -print-file-name=/package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so Кстати, программа работает успешно? (у него есть /package/host/myvendor.com в DT_RPATH?)   -  person Sean A.O. Harney    schedule 25.07.2009
comment
Я не могу сказать вам, почему это происходит, но вам действительно не следует указывать абсолютные пути к таким библиотекам. используйте -L /package/host/myvendor.com/API-R-2.0.0/Release/Libraries/ -lbgprs_stuff и подобные.   -  person nos    schedule 27.07.2009
comment
Существуют параметры ('-v' IIRC), чтобы увидеть точные командные строки, переданные программам-компонентам, вызванным gcc. Попробуйте использовать это, чтобы увидеть, сможете ли вы заметить разницу в том, как библиотеки «myvendor» и «aspl» передаются в «ld» (или в окружающих параметрах). Что-то должно подсказывать загрузчику по-разному обрабатывать два набора библиотек.   -  person Jonathan Leffler    schedule 05.09.2009

Ответы (3)


arrow_upward
1
arrow_downward

Я предполагаю, что предоставленные поставщиком библиотеки установили SONAME на полный установленный путь.

person Wez Furlong    schedule 02.08.2009

arrow_upward
0
arrow_downward

arm-linux-gcc -print-file-name не показывает ничего удивительного:

arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0.0 /package/host/aspl.es/axl-0.5.6 /lib/libaxl.so.0.0.0 arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0.0 /package/host/aspl .es/axl-0.5.6/lib/libaxl.so.0.0 arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0 /package/host/aspl.es/axl-0.5.6/lib/libaxl.so.0 arm-linux-gcc -print-file-name=/package/host/aspl.es/axl-0.5.6/lib /libaxl.so /package/host/aspl.es/axl-0.5.6/lib/libaxl.so

Полученный двоичный файл не запускается без определенного LD_LIBRARY_PATH и не имеет DT_RPATH (хотя это, безусловно, может помочь, предложения?)

Я не хочу полагаться на правильную настройку /etc/ld.so.conf, и поэтому мне нужны абсолютные пути везде.

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

сделать distclean; LDFLAGS=-L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin /arm-linux-gcc ~/wd/sources/contrib/axl/configure --prefix=/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6 --host=armv4tl -unknown-linux-gnu --disable-axl-knife --disable-axl-babel --disable-axl-log --disable-axl-test && make

сделать distclean; AXL_LIBS="-L/shared/syst/arm9-linux-abtrack/package/host/aspl.es/axl-0.5.6/lib/ -laxl -lm" AXL_CFLAGS=-I/shared/syst/arm9-linux- abtrack/package/host/aspl.es/axl-0.5.6/include/axl CC=/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/bin/arm-linux-gcc LDFLAGS=" -L/package/host/myvendor.com/arm9-linux-toolchain-2.1/prefix/arm-linux/lib" ~/wd/sources/contrib/vortex/configure --prefix=/shared/syst/arm9-linux -abtrack/package/host/aspl.es/vortex-1.1.0 --disable-http-support --disable-pull-support --disable-tunnel-support --disable-xml-rpc-support-gen -- disable-xml-rpc-support --disable-sasl-support --disable-vortex-log --disable-vortex-client --host=armv4tl-unknown-linux-gnu && make

Любые советы autofoo по встраиванию --prefix в скомпилированные библиотеки?

person Community    schedule 27.07.2009
comment
LDFLAGS=/конфигурация пути неверна. Вместо этого вы должны настроить LDFLAGS=/path. То есть дайте скрипту configure параметры в качестве аргументов, а не устанавливайте их в среде configure. Это позволяет config.status правильно поддерживать настройки. Это может быть частью проблемы, с которой вы столкнулись. - person William Pursell; 11.08.2009

arrow_upward
0
arrow_downward

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

Только на основе информации, которую вы предоставили, может ли быть так, что полные имена путей не включены для aspl, потому что указанные вами библиотеки aspl являются программными ссылками? Если вы сделаете длинный список, например, /package/host/aspl.es/vortex-1.1.0/lib/libvortex-1.1.so, он покажет, что это ссылка на libvortex-1.1.so.0 (с нет полного пути).

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

person shank    schedule 10.11.2009