osquery 仓库中 aws-sdk-cpp 第三方库的跨平台构建指南（Linux / macOS / Windows）

osquery 仓库中 aws-sdk-cpp 第三方库的跨平台构建指南Linux / macOS / Windows【免费下载链接】osquerySQL powered operating system instrumentation, monitoring, and analytics.项目地址: https://gitcode.com/gh_mirrors/os/osquery本文是一份面向 osquery 开发者的实战构建指南围绕仓库内 libraries/cmake/source/aws-sdk-cpp/README.md 这份构建笔记展开系统梳理 aws-sdk-cpp 在 osquery 中被裁剪式集成的方式并给出 Linux、macOSx86_64 / Apple Silicon、Windowsx86_64 / ARM64三套可直接执行的 CMake 配置命令。读完本文你将掌握aws-sdk-cpp 在 osquery 中服务于哪些功能模块、每个构建参数的作用与取值、以及 osquery 如何通过源码级 CMake 封装把庞大的 AWS SDK 裁剪为只包含 Firehose / Kinesis / S3 / STS / EC2 的精简子集。一、aws-sdk-cpp 在 osquery 中扮演什么角色osquery 的定位是SQL 驱动的操作系统遥测、监控与分析它本身并不需要完整的 AWS SDK。从仓库源码结构看aws-sdk-cpp 的价值集中在AWS 云日志转发上plugins/logger/aws_firehose.cpp 与 plugins/logger/aws_firehose.h 使用Aws::Firehose::Model::PutRecordBatchRequest等类型将 osquery 日志批量投递到 AWS Firehoseplugins/logger/aws_kinesis.cpp 与 plugins/logger/aws_kinesis.h 使用Aws::Kinesis::Model::PutRecordsRequest等类型将日志批量写入 Kinesis 数据流两者共享基类 plugins/logger/aws_log_forwarder.h内部以Aws::Utils::ByteBuffer承载待发送数据测试见 plugins/logger/tests/aws_kinesis_logger_tests.cpp。换句话说README 中这份构建笔记所服务的正是 osquery 的 AWS 日志插件对Aws::Firehose、Aws::Kinesis命名空间的编译期依赖。理解了这一点后面所有裁剪动作的动机就一目了然osquery 只需要 AWS SDK 的一小部分因此构建时必须按需编译而不是把整个 SDK 全量拉进来。二、仓库内的集成骨架从子模块到 CMake 目标2.1 子模块清单AWS SDK 依赖一整套 aws-c 系列底层库认证、HTTP、加密、事件流等。仓库通过 libraries/cmake/source/modules/Findaws-sdk-cpp.cmake 中的importSourceSubmodule以浅克隆方式拉取importSourceSubmodule( NAME aws-sdk-cpp NO_RECURSIVE SHALLOW_SUBMODULES src/aws-c-auth src/aws-c-cal src/aws-c-common src/aws-c-compression src/aws-c-event-stream src/aws-checksums src/aws-c-http src/aws-c-io src/aws-c-mqtt src/aws-crt-cpp src/aws-c-s3 src/aws-sdk-cpp src/s2n )s2n是 AWS 的 TLS 实现在 Linux 上随 AWS CRT 一起编译见下文源码佐证。2.2 裁剪式 CMake 封装libraries/cmake/source/aws-sdk-cpp/CMakeLists.txt 是整个集成的核心。文件末尾以awsSdkCppMain()为入口内部依次生成 6 个 SDK 组件与整套 AWS CRT/C 层function(awsSdkCppMain) generateAwsCrtCpp() generateAwsCppSdkCore() generateAwsCppSdkFirehose() generateAwsCppSdkKinesis() generateAwsCppSdkS3() generateAwsCppSdkSts() generateAwsCppSdkEc2() add_library(thirdparty_aws-sdk-cpp INTERFACE) target_link_libraries(thirdparty_aws-sdk-cpp INTERFACE thirdparty_aws-cpp-sdk-s3 thirdparty_aws-cpp-sdk-firehose thirdparty_aws-cpp-sdk-kinesis thirdparty_aws-cpp-sdk-sts thirdparty_aws-cpp-sdk-ec2 ) endfunction()从源码结构可以推断出以下设计决策按需裁剪虽然 AWS SDK 官方提供上百个服务模块这里只保留core必需底座、firehose、kinesisosquery 日志插件直接使用、s3、sts凭证相关、ec2六个模块接口目标对外暴露的是一个INTERFACE库thirdparty_aws-sdk-cpp链接到它即可获得全部上述组件CRT 底座generateAwsCrtCpp()内部递归调用generateAwsCCommon()、generateAwsCCal()、generateAwsCCIo()、generateAwsChecksums()、generateAwsCAuth()、generateAwsCHttp()、generateAwsCMqtt()、generateAwsCEventStream()、generateAwsCS3()并在PLATFORM_LINUX下额外生成s2n构成 aws-cpp-sdk-core 的依赖链core 目标以PUBLIC方式链接thirdparty_aws-crt-cpp。2.3 SDK 版本与平台后端core 组件的编译定义里明确固定了 SDK 版本与平台加密后端CMakeLists.txt L2767-L2802target_compile_definitions(thirdparty_aws-cpp-sdk-core PRIVATE ENABLE_CURL_LOGGING PUBLIC AWS_SDK_VERSION_MAJOR1 AWS_SDK_VERSION_MINOR9 AWS_SDK_VERSION_PATCH116 )平台相关的选择体现在两处加密后端Linux 编译source/utils/crypto/openssl/CryptoImpl.cpp并定义ENABLE_OPENSSL_ENCRYPTIONmacOS 编译commoncrypto/CryptoImpl.cpp并定义ENABLE_COMMONCRYPTO_ENCRYPTIONWindows 编译bcrypt/CryptoImpl.cpp并定义ENABLE_BCRYPT_ENCRYPTION平台源码与链接库POSIX 平台补充net/linux-shared与platform/linux-shared源码并链接Threads::ThreadsWindows 平台补充net/windows、platform/windows源码并链接Userenv、version、ws2_32、Wininet、winhttp、Bcrypt等系统库。2.4 平台 / 架构化的配置头文件core 与 CRT 组件的构建还依赖按平台 × 架构预生成的配置头文件存放于 libraries/cmake/source/aws-sdk-cpp/config 目录例如config/aws-cpp-sdk-core/linux/x86_64/aws/core/SDKConfig.h与VersionConfig.hconfig/aws-c-common/linux/aarch64/include/aws/common/config.hconfig/aws-crt-cpp/macos/arm64/aws/crt/Config.h等。core 组件的generateAwsCppSdkCore()会根据PLATFORM_LINUX / PLATFORM_MACOS / PLATFORM_WINDOWS与TARGET_PROCESSOR变量拼出config_path再作为target_include_directories的 SYSTEM 接口目录暴露给消费方——这正是 README 中三套构建命令背后隐藏的配置逻辑。三、Linux 构建接入 osquery 工具链README 的 Linux 部分强调一个关键点必须在主CMakeLists.txt中接入 osquery 工具链并推荐以 cmake/toolchain.cmake 作为起点。参考构建命令cmake \ -S . \ -B build \ -DBUILD_SHARED_LIBSOFF \ -DCMAKE_BUILD_TYPERelease \ -DNO_HTTP_CLIENTON \ -DOSQUERY_TOOLCHAIN_SYSROOT/usr/local/osquery-toolchain各参数作用如下参数取值说明BUILD_SHARED_LIBSOFF强制静态编译。osquery 一贯倾向静态链接第三方库便于单一二进制分发、避免运行期动态库版本漂移CMAKE_BUILD_TYPERelease以优化模式构建是发布产物的标准配置NO_HTTP_CLIENTON关闭 AWS SDK 自带的 HTTP 客户端实现。osquery 自身在 osquery/remote/http_client.cpp 维护独立 HTTP 栈日志转发走的是 osquery 自己的网络层无需为 AWS SDK 额外引入一套 HTTP 客户端OSQUERY_TOOLCHAIN_SYSROOT工具链 sysroot 路径指向 osquery 预构建的交叉/编译工具链根目录保证编译器、libc、头文件版本与 osquery 主工程一致需要说明的是OSQUERY_TOOLCHAIN_SYSROOT的具体路径取决于你的开发环境CI 镜像或本机工具链安装位置默认值并不固定构建前请按实际安装路径调整。四、macOS 构建x86_64 与 Apple SiliconmacOS 上除了静态编译与关闭 HTTP 客户端外还需要显式指定 SDK 路径、部署目标与目标架构并定位 OpenSSL。4.1 macOS x86_64cmake \ -S . \ -B build \ -DBUILD_SHARED_LIBSOFF \ -DCMAKE_BUILD_TYPERelease \ -DNO_HTTP_CLIENTON \ -DCMAKE_OSX_SYSROOT/Applications/Xcode_13.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk \ -DCMAKE_OSX_DEPLOYMENT_TARGET10.14 \ -DCMAKE_OSX_ARCHITECTURESx86_64 \ -DOPENSSL_ROOT_DIR/usr/local/Cellar/openssl1.1/1.1.1k4.2 macOS ARMM1、M2 等cmake \ -S . \ -B build \ -DBUILD_SHARED_LIBSOFF \ -DCMAKE_BUILD_TYPERelease \ -DNO_HTTP_CLIENTON \ -DCMAKE_OSX_SYSROOT/Applications/Xcode_13.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk \ -DCMAKE_OSX_DEPLOYMENT_TARGET10.15 \ -DCMAKE_OSX_ARCHITECTURESarm64 \ -DOPENSSL_ROOT_DIR/usr/local/Cellar/openssl1.1/1.1.1k两套命令仅有两处差异梳理如下参数x86_64ARM说明CMAKE_OSX_DEPLOYMENT_TARGET10.1410.15最低支持的 macOS 版本决定了可用的系统 API 面CMAKE_OSX_ARCHITECTURESx86_64arm64目标 CPU 架构Apple Silicon 上必须显式写arm64避免意外交叉编译为 x86_64其余参数含义CMAKE_OSX_SYSROOT指向 Xcode 中 macOS SDK 的绝对路径。示例使用了 Xcode 13.0 附带的MacOSX11.3.sdk实际构建时应替换为你机器上 Xcode 实际安装的 SDK 路径可执行xcodebuild -showsdks查看OPENSSL_ROOT_DIR指向 Homebrew 安装的 OpenSSL 1.1 前缀目录。示例为/usr/local/Cellar/openssl1.1/1.1.1kApple Silicon 机器上 Homebrew 前缀通常是/opt/homebrew需按实际安装位置调整。它服务于 aws-cpp-sdk-core 在 macOS 上通过 CommonCrypto 实现的加密后端ENABLE_COMMONCRYPTO_ENCRYPTION所依赖的 OpenSSL 头文件与库。五、Windows 构建x86_64 与 ARM64Windows 上使用cmd的多行续行符^组织命令参数比 macOS 简洁无需指定 SDK 路径与 OpenSSLcmake ^ -S . ^ -B build ^ -DBUILD_SHARED_LIBSOFF ^ -DCMAKE_BUILD_TYPERelease ^ -DNO_HTTP_CLIENTON这是因为 Windows 分支的 aws-cpp-sdk-core 使用系统内置的 Bcrypt 作为加密后端ENABLE_BCRYPT_ENCRYPTION并链接Wininet、winhttp、ws2_32、Bcrypt等系统库无需外部 OpenSSL架构x86_64 / ARM64则由 CMake 生成器如 Visual Studio 的架构选项决定配置头文件同样按windows/x86_64、windows/aarch64目录分别预生成见 config 目录结构。六、构建注意点与常见坑结合 README 的命令与仓库实现以下几点在实际构建中值得特别留意目录即工程以上命令的-S .是在 aws-sdk-cpp 源码根目录下执行即以 libraries/cmake/source/aws-sdk-cpp 为独立 CMake 工程进行配置。若在 osquery 主工程中集成则走的是 Findaws-sdk-cpp.cmake 的子模块导入链路再由awsSdkCppMain()生成目标静态链接是硬约束BUILD_SHARED_LIBSOFF在三个平台全部出现。aws-c 系列与 aws-sdk-cpp 的源码级集成都以静态库为目标不要在生产构建中打开共享库HTTP 客户端冲突NO_HTTP_CLIENTON关闭 AWS SDK 自带 HTTP 实现避免与 osquery 自身的网络栈osquery/remote/http_client.cpp产生重复符号或行为不一致工具链一致性Linux 上务必让 aws-sdk-cpp 与 osquery 使用同一套 cmake/toolchain.cmake 工具链含OSQUERY_TOOLCHAIN_SYSROOT否则 glibc / 编译选项不一致会导致链接期 ABI 问题平台版本号可替换macOS 的 SDK 路径、部署目标与 OpenSSL 版本都是示例值随本机 Xcode 与 Homebrew 环境变化切忌原样照抄。七、总结这份 README 虽短却浓缩了 osquery 第三方库集成的全部要点静态编译、关闭自带 HTTP 客户端、按平台显式指定工具链/架构/加密依赖、只裁剪所需服务模块。配合 libraries/cmake/source/aws-sdk-cpp/CMakeLists.txt 与 config 目录阅读你可以完整复现 osquery 对 aws-sdk-cpp 的构建过程并为自己的平台移植工作提供直接参考——无论是新增一个 AWS 服务模块还是适配一个新的编译环境都可以以这套骨架为起点。【免费下载链接】osquerySQL powered operating system instrumentation, monitoring, and analytics.项目地址: https://gitcode.com/gh_mirrors/os/osquery创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考