gcc file.c 和 g++ file.cpp 看上去只是命令不同，背后却涉及语言前端、默认链接库、ABI 和目标平台工具链。尤其在 Windows 上使用 MinGW 编译 Windows SDK 代码时，“已经找到头文件”和“这套编译器能够使用该头文件”是两件事。

一、从源文件到可执行文件

编译过程可以分为预处理、编译、汇编和链接。-c 表示只生成目标文件，不执行最终链接：

gcc -c c_part.c -o c_part.o
g++ -c cpp_part.cpp -o cpp_part.o
g++ c_part.o cpp_part.o -o app

混合工程通常分别用 C 和 C++ 编译器生成目标文件，最终使用 g++ 链接，因为它会自动加入 C++ 标准库和相应运行时。使用 gcc 链接 C++ 目标文件也可以，但需要自行补齐 C++ 库，容易出现未定义符号。

不能简单地用 g++ file.c file.cpp 代替上述流程。g++ 会把输入当成 C++ 处理，原本合法的 C 代码未必符合 C++ 规则。C 头文件供 C++ 调用时，还需要处理符号修饰：

#ifdef __cplusplus
extern "C" {
#endif

int c_api(void);

#ifdef __cplusplus
}
#endif

二、头文件是怎样被找到的

#include "local.h"
#include <system.h>

双引号通常先搜索当前源文件附近，再搜索编译器 include path；尖括号主要按 include path 搜索。项目自己的头文件一般使用双引号，系统或第三方库使用尖括号。

额外目录通过 -I 指定：

g++ -I C:/project/include -I C:/third_party/include main.cpp -o app

调试时可以让编译器打印真实搜索路径：

g++ -v -E main.cpp -o NUL

在 Makefile 中，预处理选项通常放在 CPPFLAGS，C 与 C++ 编译选项分别放在 CFLAGS、CXXFLAGS：

CPPFLAGS += -IC:/project/include
CFLAGS   += -Wall
CXXFLAGS += -Wall -std=c++17

环境变量 C_INCLUDE_PATH 和 CPLUS_INCLUDE_PATH 也能添加搜索目录，但项目构建更适合使用明确的 -I 或构建系统配置，避免依赖机器全局状态。

三、为什么复制头文件仍然编译失败

把 TraceLoggingProvider.h 复制到源码目录仍可能失败，原因包括：

• 源码仍使用尖括号且当前目录不在实际搜索路径中。
• 头文件继续包含其他 Windows SDK 头文件。
• 依赖特定编译器宏、语言扩展或内建类型。
• 编译通过后仍缺少对应库，最终在链接阶段失败。
• SDK 版本、目标架构和工具链 ABI 不一致。

可以用完整路径或双引号做一次诊断，但不建议把 SDK 头文件零散复制到项目中。正确做法是安装完整 SDK，并使用与其匹配的工具链和构建环境。

四、MSVC、MinGW 与 MSYS2

MSVC 是 Microsoft 的 C/C++ 工具链，与 Windows SDK 和 Visual Studio 构建系统配套。MinGW-w64 提供 GCC、Windows API 头文件和 import libraries，使 GCC 能生成 Windows 程序。MSYS2 则提供软件包管理和类 Unix 的构建环境，其中可以安装 MinGW-w64 工具链。

三者的关系不是“安装 GCC 后再把 Windows SDK 路径加进去”这么简单。Windows SDK 的部分接口使用 MSVC 环境验证，MinGW 自带的是另一套经过适配的 Windows 头文件和库。一个 SDK 头文件在磁盘上存在，不代表当前 MinGW 版本能够直接编译它。

检查当前实际工具链：

where gcc
where g++
gcc --version
g++ --version

在 MSYS2 中还要确认使用的是 MinGW/UCRT 终端和对应的编译器，而不是只面向 MSYS 运行时的工具。

五、TraceLoggingProvider.h 案例

TraceLoggingProvider.h 属于 Windows SDK，用于生成 Windows ETW TraceLogging 事件。代码通常类似：

Windows ETW 与 TraceLogging 的整体结构可参考《Windows ETW 框架》；Linux 下的兼容实现则可参考《Linux LTTng 框架》。

#ifdef _WIN32
#include <windows.h>
#include <TraceLoggingProvider.h>
#else
#include <tracelogging/TraceLoggingProvider.h>
#endif

这里应优先使用标准的 _WIN32 宏，而不是只判断 WIN32。如果 Windows 分支使用原生 ETW TraceLogging，最稳妥的是在 Visual Studio Developer Command Prompt 中使用 MSVC，并由项目配置选择 Windows SDK 版本。

如果目标平台是 Linux，<tracelogging/TraceLoggingProvider.h> 通常来自 LTTng 相关的兼容实现，需要安装对应开发包并按其文档链接 LTTng 库；它不是 Windows SDK 中同名文件的简单复制品。

排查顺序如下：

1. 确认实际进入了哪个 #ifdef 分支。
2. 确认使用的编译器和目标平台。
3. 用预处理命令检查 include 搜索路径。
4. 确认头文件属于哪个 SDK 或开发包。
5. 确认它依赖的其他头文件和链接库完整。
6. 对 Windows 原生 TraceLogging 优先使用 MSVC；对 Linux 兼容实现使用对应的 LTTng 工具链。

因此，fatal error: TraceLoggingProvider.h: No such file or directory 有时确实只是 -I 配置问题，但如果加路径和复制文件都无效，就应该转向检查平台分支、SDK 完整性和工具链兼容性，而不是继续堆叠 include path。