1. 编译 OpenClaw 时 duplicate symbol _claw_global_config 到底在说什么
duplicate symbol _claw_global_config in: claw_config.o and main.o这个报错，是 OpenClaw 在链接阶段抛出来的。它说的是：链接器在claw_config.o和main.o两个目标文件里，都找到了名为_claw_global_config的全局符号，而且这两个符号都是「强定义」，链接器不知道该保留哪一个，于是直接报错退出。注意报错发生在链接阶段而不是编译阶段，所以claw_config.cpp和main.cpp单独编译时都不会报错，只有把.o文件拼成可执行文件时才炸。
这个符号名前面的下划线是 macOS 和部分平台的命名习惯，Linux 上nm看到的是_claw_global_config或claw_global_config，本质是同一个全局变量。它通常是一个配置结构体实例，比如ClawConfig _claw_global_config;，被写在了头文件里，或者被两个.cpp文件各自定义了一遍。
适合谁看：正在编译 OpenClaw、被这个 duplicate symbol 卡住、想搞清楚 extern 声明和单一定义到底怎么写的同学。下面我会从定位符号、改头文件、改 Makefile 编译顺序，到用nm验证符号唯一性，一步步走完。
2. 先定位：用 nm 和 grep 确认符号到底在哪几个目标文件里重复
在动手改代码之前，先别猜。链接器已经告诉你重复的是claw_config.o和main.o，但你要确认这两个.o里符号的类型，是T（代码段）、D（已初始化数据）、B（未初始化数据）还是U（未定义引用）。只有两个都是定义（D/B/T）才会冲突，如果一个是U一个是D，那反而是正常的。
# 进入你的构建目录，找到这两个目标文件 cd ~/openclaw/build # 查看 claw_config.o 里的符号 nm claw_config.o | grep claw_global_config # 查看 main.o 里的符号 nm main.o | grep claw_global_config如果输出类似下面这样，两个都是D或B，那就是重复定义：
0000000000000000 D _claw_global_config # claw_config.o 0000000000000000 D _claw_global_config # main.o接着回到源码，看这个符号在哪些文件里被「定义」（不带 extern 的那种）：
# 在源码目录里全局搜索 cd ~/openclaw grep -rn "claw_global_config" src/ include/ # 重点看头文件里是不是直接写了定义 grep -n "claw_global_config" include/claw_config.h注意：
grep出来的行如果前面没有extern，而且不在函数体内，那基本就是定义。头文件里出现这种定义，是最常见的元凶。
3. TaoToken 前置：把模型对话和接入文档准备好，边改边问
改这种链接错误，很多时候需要反复确认「extern 声明写在头文件、定义写在 .cpp」这个规则，或者让模型帮你解释nm输出。我习惯把 TaoToken 的模型对话页面开着，遇到不确定的符号类型就直接问。
TaoToken 是一个大模型 API 聚合平台，你可以把它理解成一个统一的入口，用同一套 API Key 去调用不同厂商的模型。对这次排障来说，它的用处是：当你对extern、static、单例这几种写法拿不准时，可以直接在对话里贴代码让它帮你判断哪个是定义、哪个是声明。
- 模型对话（边改边问）：https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- 接入文档（看 API 怎么调）：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- API Keys 管理（生成 Key）：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
如果你只是偶尔问几句，用模型对话就够了；如果你打算把 OpenClaw 的配置解析、日志分析接进一个长期跑的 Agent 里，那更适合用 Coding Plan，后面第 6 节会说。
4. 可复制配置：头文件 extern 声明 + 单一定义 + Makefile 编译顺序
核心原则只有一句话：头文件里只放extern声明，定义只在一个.cpp里出现一次。下面给出config.h/config.c的骨架，以及 Makefile 里目标文件的顺序调整。
4.1 config.h：只声明，不定义
/* config.h - OpenClaw 配置头文件 */ #ifndef CLAW_CONFIG_H #define CLAW_CONFIG_H #include <stdint.h> /* 配置结构体 */ typedef struct { char device[64]; int baudrate; int timeout; int retry_count; int log_level; } ClawConfig; /* 关键：这里只做 extern 声明，绝不写定义 */ extern ClawConfig _claw_global_config; /* 对外接口 */ ClawConfig* get_global_config(void); void init_global_config(void); void cleanup_global_config(void); #endif /* CLAW_CONFIG_H */4.2 config.c：唯一一次定义
/* config.c - 全局配置的唯一实现 */ #include "config.h" #include <string.h> /* 全项目唯一一次定义，放在这里 */ ClawConfig _claw_global_config; ClawConfig* get_global_config(void) { return &_claw_global_config; } void init_global_config(void) { strncpy(_claw_global_config.device, "/dev/ttyUSB0", sizeof(_claw_global_config.device) - 1); _claw_global_config.baudrate = 115200; _claw_global_config.timeout = 1000; _claw_global_config.retry_count = 3; _claw_global_config.log_level = 2; } void cleanup_global_config(void) { memset(&_claw_global_config, 0, sizeof(_claw_global_config)); }4.3 main.c：只 include，不再定义
/* main.c - 主程序 */ #include "config.h" #include <stdio.h> int main(void) { init_global_config(); ClawConfig* cfg = get_global_config(); printf("device=%s baudrate=%d\n", cfg->device, cfg->baudrate); cleanup_global_config(); return 0; }4.4 Makefile：调整编译顺序，确保 config.o 先于 main.o
链接顺序本身不会消除重复定义，但把定义所在的config.o放在前面，能让链接器先拿到定义，main.o里如果还有残留定义会立刻暴露出来，方便你确认是否改干净了。
CC = gcc CFLAGS = -Wall -Wextra -Iinclude TARGET = openclaw # 注意顺序：config.o 放在 main.o 前面 OBJS = build/config.o build/main.o all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(OBJS) -o $@ build/config.o: src/config.c include/config.h @mkdir -p build $(CC) $(CFLAGS) -c src/config.c -o $@ build/main.o: src/main.c include/config.h @mkdir -p build $(CC) $(CFLAGS) -c src/main.c -o $@ clean: rm -rf build $(TARGET) .PHONY: all clean提示：如果你的 OpenClaw 用的是 CMake，把
config.c编成一个静态库claw_config，再让main链接这个库，也能从结构上避免重复定义。关键是别把config.c同时编进两个 target。
5. 验证请求与成功结果：用 nm 确认符号唯一性
改完之后不要急着跑，先用nm验证符号在目标文件里的分布。理想状态是：config.o里是D或B（定义），main.o里是U（未定义引用）。
# 重新编译 make clean && make # 验证 config.o：应该是 D 或 B nm build/config.o | grep claw_global_config # 验证 main.o：应该是 U nm build/main.o | grep claw_global_config期望输出：
0000000000000000 B _claw_global_config # config.o，定义 U _claw_global_config # main.o，引用如果main.o里还是D或B，说明main.c里还有残留定义，回去删掉。最后跑一下程序：
./openclaw # 输出：device=/dev/ttyUSB0 baudrate=115200链接不再报duplicate symbol，程序正常输出配置，就说明符号唯一性已经成立。
6. 本篇常见错排查：extern 写错、static 误用、头文件重复包含
错误一：头文件里写了定义，只加了 extern 关键字但位置不对。比如extern ClawConfig _claw_global_config = {...};，带初始化的 extern 仍然是定义，链接器照样报重复。extern 后面不能跟初始化。
错误二：在 .cpp 里给定义加了 static。static ClawConfig _claw_global_config;会让符号变成文件内私有，main.o里就找不到它，链接时报undefined symbol。static 只适合「这个变量只在本文件用」的场景，跨文件共享配置不能用。
错误三：头文件缺少 include guard。如果config.h被间接包含两次，而里面又恰好有定义，就会在同一个.o里产生重复。加上#ifndef / #define / #endif是基本操作。
错误四：Makefile 把同一个源文件编进了两个 target。比如config.c既编进claw_config库，又编进main可执行文件，链接时自然重复。检查OBJS列表，确保每个.c只出现一次。
错误五：C++ 项目里忘了extern "C"。如果 OpenClaw 混编 C 和 C++，头文件里的声明要包在extern "C" { }里，否则 C++ 的名称修饰会让链接器找不到 C 里定义的符号，表现为 undefined 而不是 duplicate，但同样卡编译。
排查顺序建议：先nm看两个.o的符号类型，再grep源码找定义位置，最后检查 Makefile/CMake 的目标划分。三步走完，基本能定位。
7. 把排障流程接进长期 Agent：Coding Plan 与接入文档
如果你只是偶尔编译一次 OpenClaw，上面手动改完就够了。但如果你在持续迭代 OpenClaw，或者想把「编译报错 → 自动定位符号 → 给出修复建议」做成一个长期跑的 Agent，那每次手动开对话页效率太低。这种情况更适合用 Coding Plan，把模型调用固化到你的工具链里，配合接入文档里的 API 说明，写一个脚本自动抓nm输出并请求分析。
- 长期编码 / Agent 场景，用 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- 接入细节看文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
- 生成和管理 Key：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite
我自己的做法是：在 Makefile 的all目标后面挂一个analyze目标，编译失败时把nm结果和报错行一起发给模型，让它判断是 extern 缺失还是重复定义。这样下次再遇到duplicate symbol，不用从头翻这篇文章，直接跑脚本就行。
