背景
对于实际嵌入式开发来说，交叉编译出一个目标架构的 ELF 通常不是最困难的部分。更关键的问题在于工程化集成：目标系统的 libc、编译器版本、sysroot、第三方库、动态链接、SDK 构建体系，以及最终如何被 Buildroot/OpenWrt/Yocto 这类系统编译和打包。
单片机裸机工程、或者 Ubuntu ARM / Debian ARM 这类主流发行版目标相对简单，暂时不作为这个 issue 的重点。这里主要讨论更常见的嵌入式 Linux 场景，例如：
- Buildroot
- OpenWrt
- Yocto
- 使用 uClibc/musl/glibc + 厂商定制交叉工具链的系统
核心问题 1：旧版/厂商定制编译器与 C++23 的矛盾
很多嵌入式系统的根文件系统本身也是由指定交叉工具链构建出来的。
例如某个厂商 SDK 只提供 GCC 8.3，并且整个 rootfs、libc、系统库、第三方库都使用这个 GCC 8.3 构建。实际项目中甚至可能遇到：
- uClibc 依赖特定版本工具链
- RISC-V 工具链是厂商定制版本
- libc / libstdc++ / ABI 与厂商工具链强绑定
- 升级系统编译器版本等于重做整个 SDK，成本很高
- 有些 SDK 根本没有可行的升级路径
这种情况下，mcpp 如果需要 C++23 编译器，是否还能编译出运行在该系统上的 C++23 程序？
我目前没有想到一个清晰的实现方式。因为问题不只是 mcpp 自身能否运行，而是目标程序最终要链接到该系统的 libc、libstdc++、动态链接器和 sysroot。即使 mcpp 自身可以在 host 上运行，target 侧如果只能使用 GCC 8.3，也很难真正编译 C++23 代码。
所以我想明确 mcpp 对这类场景的定位：
- mcpp 是否只支持目标工具链本身具备 C++23 能力的嵌入式系统？
- 是否可能支持“host 使用现代 mcpp，但 target 使用 SDK 内旧编译器”的模式？
- 对于厂商锁死工具链版本的 SDK，mcpp 有没有推荐路线？
核心问题 2：与 Buildroot/OpenWrt/Yocto SDK 的集成方式
在真实嵌入式系统中，应用通常不是单独手写一条交叉编译命令完成的，而是要接入系统构建体系。
以 Buildroot 为例，通常需要：
- 用 Makefile / Kconfig 管理包
- 使用 Buildroot 提供的
TARGET_CC / TARGET_CXX
- 使用 Buildroot 生成的 staging sysroot
- 依赖 Buildroot 的 package 机制准备第三方库
- 最终由 Buildroot 负责安装到 target rootfs 或生成固件镜像
Rust 在 Buildroot 中就是类似模式：Buildroot 内部维护 rustc/cargo 的构建和打包逻辑，由 Buildroot 控制版本、target、sysroot 和安装过程。但 Rust 也会受到 rustc 版本限制，这一点在 C++23 场景下可能更明显。
所以问题是：mcpp 如果要用于这类嵌入式系统，是否需要提供一种“外部 SDK/sysroot 集成模式”，而不是只管理自己的工具链？
期望讨论的方向包括：
- mcpp 是否支持使用外部 SDK 提供的交叉编译器？
- 是否支持显式指定 sysroot？
- 是否支持继承 Buildroot/OpenWrt/Yocto 注入的编译、链接、pkg-config 环境？
- 是否支持作为 Buildroot/OpenWrt/Yocto package 的 build backend 被调用？
核心问题 3：第三方库管理与动态链接
嵌入式 C++ 项目还有一个关键问题是第三方库链接。
Rust 程序很多时候倾向于全静态链接，集成到嵌入式系统里相对直接。但 C++ 项目不一定能这样处理。很多实际场景强依赖系统动态库，例如音频开发常见的 ALSA：
libasound.so- 插件机制
- 配置文件
- 运行时动态加载
- 与 rootfs 中其他库的 ABI 兼容
即使某些库理论上可以静态链接，实际系统中也经常必须使用动态链接。
因此，如果 mcpp 集成到 Buildroot/OpenWrt/Yocto 构建体系中，它需要能适配这些系统的交叉动态链接模型：
- 第三方库由 Buildroot/OpenWrt/Yocto 的 package/Kconfig 体系编译进 sysroot
- C++ 应用从该 sysroot 中查找头文件和库
- 链接时使用 target 动态链接器、rpath/runpath 或系统默认搜索路径
- 不破坏目标 rootfs 的 ABI 和 libc 约束
- 能够正确处理
pkg-config、-I、-L、-l、动态库依赖等信息
也就是说，问题不只是“mcpp 自己能不能下载依赖”，而是 mcpp 能否很好地消费嵌入式 SDK 已经管理好的 sysroot 和第三方库。
期望能力
我希望 mcpp 未来能支持一种更贴近嵌入式 Linux SDK 的工作流。
期望至少能支持：
- 外部交叉工具链
- 外部 sysroot
- SDK 提供的 target 编译/链接 flags
- target
pkg-config
- 动态链接到 sysroot 中的第三方库
- 与 Buildroot/OpenWrt/Yocto package 构建流程集成
- 当目标编译器不支持 C++23 时给出明确诊断
希望讨论的问题
- mcpp 对 Buildroot/OpenWrt/Yocto 这类嵌入式 Linux SDK 的定位是什么？
- mcpp 是否计划支持外部 SDK/sysroot，而不是只使用 mcpp 自己管理的工具链？
- 如果厂商 SDK 只能使用 GCC 8.3 这类旧编译器，mcpp 是否有可行方案编译 C++23 项目？
- mcpp 是否可以作为 Buildroot/OpenWrt/Yocto 的 package build backend？
- 第三方动态库链接应该由 mcpp 管理，还是主要消费 SDK/sysroot/pkg-config 提供的信息？
背景
对于实际嵌入式开发来说，交叉编译出一个目标架构的 ELF 通常不是最困难的部分。更关键的问题在于工程化集成：目标系统的 libc、编译器版本、sysroot、第三方库、动态链接、SDK 构建体系，以及最终如何被 Buildroot/OpenWrt/Yocto 这类系统编译和打包。
单片机裸机工程、或者 Ubuntu ARM / Debian ARM 这类主流发行版目标相对简单，暂时不作为这个 issue 的重点。这里主要讨论更常见的嵌入式 Linux 场景，例如：
核心问题 1：旧版/厂商定制编译器与 C++23 的矛盾
很多嵌入式系统的根文件系统本身也是由指定交叉工具链构建出来的。
例如某个厂商 SDK 只提供 GCC 8.3，并且整个 rootfs、libc、系统库、第三方库都使用这个 GCC 8.3 构建。实际项目中甚至可能遇到：
这种情况下，mcpp 如果需要 C++23 编译器，是否还能编译出运行在该系统上的 C++23 程序？
我目前没有想到一个清晰的实现方式。因为问题不只是 mcpp 自身能否运行，而是目标程序最终要链接到该系统的 libc、libstdc++、动态链接器和 sysroot。即使 mcpp 自身可以在 host 上运行，target 侧如果只能使用 GCC 8.3，也很难真正编译 C++23 代码。
所以我想明确 mcpp 对这类场景的定位：
核心问题 2：与 Buildroot/OpenWrt/Yocto SDK 的集成方式
在真实嵌入式系统中，应用通常不是单独手写一条交叉编译命令完成的，而是要接入系统构建体系。
以 Buildroot 为例，通常需要：
TARGET_CC/TARGET_CXXRust 在 Buildroot 中就是类似模式：Buildroot 内部维护 rustc/cargo 的构建和打包逻辑，由 Buildroot 控制版本、target、sysroot 和安装过程。但 Rust 也会受到 rustc 版本限制，这一点在 C++23 场景下可能更明显。
所以问题是：mcpp 如果要用于这类嵌入式系统，是否需要提供一种“外部 SDK/sysroot 集成模式”，而不是只管理自己的工具链？
期望讨论的方向包括：
核心问题 3：第三方库管理与动态链接
嵌入式 C++ 项目还有一个关键问题是第三方库链接。
Rust 程序很多时候倾向于全静态链接，集成到嵌入式系统里相对直接。但 C++ 项目不一定能这样处理。很多实际场景强依赖系统动态库，例如音频开发常见的 ALSA：
libasound.so即使某些库理论上可以静态链接，实际系统中也经常必须使用动态链接。
因此，如果 mcpp 集成到 Buildroot/OpenWrt/Yocto 构建体系中，它需要能适配这些系统的交叉动态链接模型：
pkg-config、-I、-L、-l、动态库依赖等信息也就是说，问题不只是“mcpp 自己能不能下载依赖”，而是 mcpp 能否很好地消费嵌入式 SDK 已经管理好的 sysroot 和第三方库。
期望能力
我希望 mcpp 未来能支持一种更贴近嵌入式 Linux SDK 的工作流。
期望至少能支持：
pkg-config希望讨论的问题