BitBake: пример не найден в базовых лентах

У меня есть рецепт BitBake (example_0.1.bb) с задачей do_install, где я пытаюсь установить файл .so:

do_install() {
    install -d ${D}${libdir}
    install -m 0644 ${S}/example.so ${D}${libdir} 
}
FILES_${PN} += "${libdir}/example.so"

Это терпит неудачу во время процесса сборки и возвращает:

ERROR: example not found in the base feeds

Однако, если я добавлю тестовый файл в пакет, и файл .so, и тестовый файл будут добавлены в rootfs.

do_install() {
    install -d ${D}${libdir}
    install -m 0644 ${S}/example.so ${D}${libdir} 
    echo "bar" >> ${TOPDIR}/foo
    install -m 0644 ${TOPDIR}/foo ${D}${libdir} 
}
FILES_${PN} += "${libdir}/libceill.so"
FILES_${PN} += "${libdir}/foo"

Как я могу добавить только файл .so без тестового файла нежелательной почты?


yocto package openembedded bitbake dynamic-library
person karobar    schedule 29.01.2016    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Итак, у вас есть нестандартная библиотека, которая не устанавливает версионную библиотеку (libfoo.so.1.2.3, возможно, символические ссылки, такие как libfoo.so.1 -> libfoo.so.1.2.3), и затем неверсионная символическая ссылка на время компиляции (libfoo.so -> libfoo.so.1). Правила упаковки по умолчанию предполагают использование стандартных библиотек.

Что происходит, так это то, что пакеты заполняются в соответствии с их порядком в ПАКЕТАХ, где PN-dev стоит перед PN. FILES_PN-dev по умолчанию содержит /usr/lib/lib*.so, а FILES_PN содержит /usr/lib/lib*.so.. Когда вы добавляете /usr/lib/lib.so в FILES_PN, то, что вы хотите, не происходит, потому что PN-dev уже взял файлы.

Если ваша библиотека вообще не поставляется с какими-либо файлами разработки (например, без заголовков), вы можете установить FILES_${PN}-dev = "" для очистки этого пакета, а затем добавить lib*.so в FILES_${ PN} будет работать как положено.

Да, это то, что мы должны упростить (я думал о небольшом классе для таких библиотек) и предупреждать при проверках работоспособности, когда это происходит.

О, и я удивлен, что библиотека оказывается на изображении во втором примере, так как пример будет содержать /usr/lib/foo, а example-dev будет содержать /usr/lib/libceill.so. Если, конечно, у вас не включен dev-pkgs, который автоматически установит example-dev, если у вас есть пример в образе.

person Ross Burton    schedule 29.01.2016

arrow_upward
1
arrow_downward

Добавьте строку

FILES_SOLIBSDEV = ""

Объяснение из списка рассылки Yocto:

У меня были FILES_${PN} += «${libdir}/.so», и это не сработало. Может быть, это было из-за того, что я пропустил FILES_SOLIBSDEV = "", о котором вы упомянули. Я поиграю с ним еще немного и посмотрю, что произойдет. Сначала я начал с FILES_${PN} += "${libdir}/ .so", а когда это не сработало, я попробовал другие вещи в строке FILES_${PN} =, чтобы попытаться ее подобрать. Когда я не смог заставить ничего работать, а затем увидел другие (ну, по крайней мере, ссылка, которую я предоставил) видел то же самое, я подумал, что пришло время перестать крутить колеса и обратиться к большим пушкам :)

Хех :) Проблема в том, что шаблоны сопоставляются в порядке переменной PACKAGES. Первый пакет, включающий файл, получает его, и ${PN}-dev находится в PACKAGES перед ${PN}. Очистка FILES_SOLIBSDEV удалит .so из FILES_${PN}-dev, позволив вместо этого получить его пакету ${PN}.

person karobar    schedule 29.01.2016
comment
Установка FILES_SOLIBSDEV - самый странный способ исправить это, который я видел. - person Ross Burton; 29.01.2016
comment
да, правда? Есть ли лучший/стандартный способ сделать это? - person karobar; 29.01.2016
comment
Да, смотрите мой ответ ниже. Настройка FILES_SOLIBSDEV, я думаю, работает, если у вас нет символических ссылок libfoo.so, но все еще установлены заголовки, что, как мне кажется, довольно необычно. - person Ross Burton; 30.01.2016

arrow_upward
1
arrow_downward

Добавьте строку: FILES_${PN}_dev_remove="${FILES_SOLIBDEV}" Это переместит пакет для пути разработки.

person MohitKLulla    schedule 14.07.2017