bitbake grpc кросс-компиляция / конфигурирование завершается неудачно с ошибкой c-ares::cares ссылается на файл /usr/lib/libcares.so.2.2.0

Question

У меня возникают проблемы с поиском зависимостей c-ares при сборке grpc в open-внедрено. Ошибка в журнале при поиске зависимостей c-ares во время настройки отображается в журнале как -

-

Found ZLIB: ....../poky/build/tmp-glibc/sysroots/arm7/usr/lib/libz.so (found version "1.2.8")
CMake Error at ....../poky/build/tmp-glibc/sysroots/arm7/usr/lib/cmake/c-ares/c-ares-targets.cmake:70 (message):
   The imported target "c-ares::cares" references the file
      "/usr/lib/libcares.so.2.2.0"

but this file does not exist.  Possible reasons include:

   * The file was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and contained

    "/home/...../poky/build/tmp-glibc/sysroots/arm7/usr/lib/cmake/c-ares/c-ares-targets.cmake"
   but not all the files it references.

-

Кажется, проблема заключается в том, как cmake настроил префикс импорта для c-ares, который настраивается, как показано ниже в файле - poky/build/tmp-glibc/sysroots/arm7/usr/lib/cmake/c-ares/c-ares-targets.cmake. Я считаю, что это должен быть путь к целевой промежуточной директории

set(_IMPORT_PREFIX "/usr")

Может кто-нибудь, пожалуйста, помогите мне определить проблему здесь? что нужно настроить в рецепте c-ares, чтобы получить _IMPORT_PREFIX правильно?? Буду признателен за любую оказанную помощь. Спасибо

Answer 1

Я столкнулся с этой проблемой сегодня, когда строил новый gRPC в более старой (последовательной) среде BitBake. Решения, к которым я пришел, заключались в том, чтобы либо перенести это восходящее изменение в cmake.bbclass, либо взломать обновленные определения переменных в.bbappend для вызова cmake посредством EXTRA_OECMAKE переменная.

Я выбрал последнее, поскольку мне казалось, что это нужно только для c-ares, и хотел ограничить свое влияние. Я не стал копаться в разнице между тем, как c-ares и другие зависимости gRPC (например, gflags) генерируют файлы целей экспорта CMake. Я предполагаю, что каким-то образом конечные целевые пути генерируются в файлах CMakeLists.txt соответствующих проектов.

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a8ed..5203d8aca1 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
      ${OECMAKE_SITEFILE} \
      ${OECMAKE_SOURCEPATH} \
      -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
-     -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
-     -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
-     -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
+     -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir', True), d.getVar('prefix', True))} \
+     -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir', True), d.getVar('prefix', True))} \
+     -DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir', True), d.getVar('prefix', True))} \
      -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
-     -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
+     -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir', True), d.  getVar('prefix', True))} \
      -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
-     -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
-     -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
-     -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+     -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir', True), d.getVar('prefix', True))} \
+     -DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir', True), d.getVar('prefix', True))} \
+     -DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir', True), d.getVar('prefix', True))} \
      -DCMAKE_INSTALL_SO_NO_EXE=0 \
      -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
      -DCMAKE_VERBOSE_MAKEFILE=1 \