LINUX.ORG.RU

Buildroot. Символическая ссылка на .so файл

 ,


0

1

Через механизм br2-external добавил пакеты, которые собираются в *.so файлы. Все из них собираются с помощью обычного Makefile. В мануале написано, что в таком случае надо в libfoo.mk файле поступать следующим образом:

define LIBFOO_INSTALL_TARGET_CMDS
     $(INSTALL) -D -m 0755 $(@D)/libfoo.so* $(TARGET_DIR)/usr/lib
     $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/foo.d
endef

Как я и сделал в своём *.mk файле. Есть файл libfoo.so.1.2.3, на него должны быть символические ссылки libfoo.so.1 и libfoo.so. Они не создаются. Как правильно сделать, чтобы они создавались при сборке?

Для пакетов, что уже прилагаются к buildroot, эти ссылки создаются, но я так и не смог найти в каком месте. В мануале об этом ничего.

Есть файл libfoo.so.1.2.3, на него должны быть символические ссылки libfoo.so.1 и libfoo.so. Они не создаются. Как правильно сделать, чтобы они создавались при сборке?

А они разве не при выполнении ldconfig создаются?

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

Судя по всему, вы правы. Видимо другие пакеты, которые в buildroot они на этапе сборки самого пакета создают симлинки. А там они уже все разом идут в target/.

Jullyfish
() автор топика
Ответ на: комментарий от anonymous

С хрена ли они должны создаваться, если ты их не создаёшь? Нет, за тебя их никто не создаст, ни install, ни ldconfig.

Читаем man ldconfig самое первое предложение в DESCRIPTION:

ldconfig creates the necessary links and cache...  

Проверил - удалил линки на libmodbus.5.0.2 запустил ldconfig, появился свеже-созданный линк libmodbus.so.5

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

install вообще не умеет создавать символических связей

Это понятно. Но не понятно как в buildroot принято добавлять эти симлинки. Это вполне мог быть какой-то post-build.sh скрипт или ещё чего.

Тут скорее вопрос: «Как принято в buildroot эти симлинки делать?»

Jullyfish
() автор топика
Ответ на: комментарий от Jullyfish

я так понимаю, что каждый пакет сам по себе выполняет make install и эта хрень делает все нужные симлинки, вот например mk файл пакета zlib-ng


ZLIB_NG_VERSION = 2.1.6
ZLIB_NG_SITE = $(call github,zlib-ng,zlib-ng,$(ZLIB_NG_VERSION))
ZLIB_NG_LICENSE = Zlib
ZLIB_NG_LICENSE_FILES = LICENSE.md
ZLIB_NG_INSTALL_STAGING = YES
ZLIB_NG_PROVIDES = zlib

# Build with zlib compatible API, gzFile support and optimizations on
ZLIB_NG_CONF_OPTS += \
        -DCMAKE_C_COMPILER_TARGET=$(BR2_ARCH) \
        -DWITH_GZFILEOP=1 \
        -DWITH_OPTIM=1 \
        -DZLIB_COMPAT=1 \
        -DZLIB_ENABLE_TESTS=OFF

# Enable ACLE on ARM
ifeq ($(BR2_arm),y)
ZLIB_NG_CONF_OPTS += -DWITH_ACLE=1
endif

ifeq ($(BR2_ARM_CPU_HAS_NEON)$(BR2_aarch64),y)
ZLIB_NG_CONF_OPTS += -DWITH_NEON=ON
else
ZLIB_NG_CONF_OPTS += -DWITH_NEON=OFF
endif

ifeq ($(BR2_powerpc_power8),y)
ZLIB_NG_CONF_OPTS += -DWITH_POWER8=ON
else
ZLIB_NG_CONF_OPTS += -DWITH_POWER8=OFF
endif

ifeq ($(BR2_powerpc_power9),y)
ZLIB_NG_CONF_OPTS += -DWITH_POWER9=ON
else
ZLIB_NG_CONF_OPTS += -DWITH_POWER9=OFF
endif

$(eval $(cmake-package))

видимо eval выполняет все по стандартному сценарию, включая создание симлинков

IvanRia
()
Ответ на: комментарий от Jullyfish

а вот нашел пакет, в котором прямо создаются линки

/package/kodi/kodi.mk строка 418 и далее, правда, с библиотеками это не связано, но никто не мешает вам написать что-то похожее

IvanRia
()
Ответ на: комментарий от sigurd

В Linux эта недофича не используется, а например, bsd’шные ldconfig’и её вообще не поддерживают. Она бесполезна и опасна - линками на библиотеки управляет пакетный менеджер, при этом он следит за тем чтобы версия библиотеки на которую указывает ссылка совпадала с версией заголовочных файлов от неё (обычно и хедеры и ссылка приезжают в одном пакете). ldconfig про заголовки ничего не знает, и если версий библиотеки установлено несколько, создаст ссылку на непонятно какую из них. Если она будет иной версии нежели заголовки, собранный с этими заголовками и слинкованный с библиотекой по ссылке софт будет сломан.

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

Я про это поведение ldconfig либо не знал, либо не помнил. Но тебе возражу. Почему это непонятно на какую? К lib.so.5.0.2 делает алиас lib.so.5 - это не может ничего сломать. Если там есть lib.so.5.0.2 и lib.so.5.5.3 - они должны быть полностью взаимозаменяемы уже после компиляции, то есть не важно на какую будет симлинк, сломаться ничего не должно. При изменении интерфейса должна меняться первая цифра, и именно поэтому симлинки устроены именно так. lib.so - симлинк для компилятора, чтобы тот, при компиляции, нашёл хоть какую-нить версию библиотеки (и хедеры должны быть от неё же, точнее от кого-нить с той же «мажорной» версией). lib.so.5 - симлинк для рантайм линкера, чтобы тот нашёл библиотеку с подходящим интерфейсом.

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