在Yocto中通过CMake获取sysroot目录及第三方库非标准构建处理

Got it, let's walk through how to solve this Yocto + CMake issue with your unmodifiable third-party libs. I’ve dealt with similar non-standard build setups before, so here’s a practical approach:

1. Grab the Yocto Sysroot Path in CMake #

Yocto exposes the target sysroot via the OECORE_TARGET_SYSROOT environment variable when you’re working in the build shell (after running source poky/oe-init-build-env). In CMake, you can directly reference this to point to the correct sysroot:

# Set the sysroot from Yocto's environment variable
set(CMAKE_SYSROOT $ENV{OECORE_TARGET_SYSROOT})

This ensures CMake looks for headers, libraries, and tools in the Yocto-built sysroot instead of your host system.

2. Fix libA’s Non-Standard Header Reference to libB #

Since libA uses #include "headerB.h" (instead of the standard <headerB.h>) and relies on -I to find libB’s include dir, you need to explicitly add libB’s include path to libA’s interface includes in CMake. Here’s how:

First, locate libB’s headers and library in the sysroot:

# Find libB's header and library files in the Yocto sysroot
find_path(LIBB_INCLUDE_DIR 
    NAMES headerB.h 
    PATHS ${CMAKE_SYSROOT}/path/to/libB/include  # Adjust this to where libB installs its headers
    NO_DEFAULT_PATH
)

find_library(LIBB_LIBRARY 
    NAMES libB.so libB.a  # Match libB's actual library name
    PATHS ${CMAKE_SYSROOT}/path/to/libB/lib  # Adjust to libB's library install path
    NO_DEFAULT_PATH
)

Then, set up libA as an imported target, making sure to include libB’s header directory in its interface:

# Import the pre-built libA (since you can't modify it)
add_library(libA STATIC IMPORTED)  # Use SHARED if libA is a shared library
set_target_properties(libA PROPERTIES
    IMPORTED_LOCATION ${CMAKE_SYSROOT}/path/to/libA/lib/libA.a  # Path to libA's binary
    INTERFACE_INCLUDE_DIRECTORIES "${CMAKE_SYSROOT}/path/to/libA/include;${LIBB_INCLUDE_DIR}"
)

The INTERFACE_INCLUDE_DIRECTORIES ensures any target linking against libA automatically gets both libA and libB’s header paths, which fixes the "headerB.h" include issue.

3. Handle Special Link Logic for libA #

If libA has unusual link requirements (like specific linker flags or dependency order), you can add those to the imported target’s interface:

set_target_properties(libA PROPERTIES
    INTERFACE_LINK_OPTIONS "-Wl,--special-flag;--another-linker-option"
)

This propagates the special flags to any target that links against libA.

4. Yocto Recipe Tweaks (If You’re Packaging libA/libB) #

If you’re creating Yocto recipes for libA and libB, make sure:

• For libB’s recipe: Install its headers to the staging sysroot so CMake can find them. Add this to your recipe:

  FILES_${PN}-dev += "${datadir}/libB/include/"  # Adjust path to match libB's include dir
  

• For libA’s recipe: Pass the libB include path to CMake during the build. Add this to your recipe:

  EXTRA_OECMAKE += "-DLIBB_INCLUDE_DIR=${STAGING_INCDIR}/libB"
  

Final Notes #

The core of the problem is bridging libA’s non-standard include syntax with Yocto’s sysroot structure. By explicitly mapping libB’s include path to libA’s interface in CMake, and ensuring Yocto stages the libraries correctly, you’ll get the build working without modifying the third-party code.

内容的提问来源于stack exchange，提问作者PoVa