跨编译单元共享静态链接的C代码拆分方案咨询

可行方案：实现仅内部可见的共享逻辑 #

你要的「仅对拆分后.c文件可见的头文件」完全可以实现，核心是利用C的编译特性，让共享符号只在你的模块内部生效，同时避免和外部项目的同名符号冲突，完全不需要放弃拆分。

方案1：用static inline重构小型共享静态函数 #

如果要共享的静态函数代码量不大，直接把它们的实现放到内部头文件里，用static inline声明：

// internal_shared.h
#ifndef INTERNAL_SHARED_H
#define INTERNAL_SHARED_H

// 原静态函数改为static inline，实现直接写在头文件
static inline int my_static_func(int arg) {
    // 原函数的逻辑代码
    return arg + 1;
}

// 共享的结构体定义
typedef struct {
    int val;
} my_shared_struct;

#endif

之后在你拆分的两个.c文件里#include "internal_shared.h"即可。每个.c文件会生成自己的static inline函数副本，既不会和外部同名符号冲突，也不用重复写代码，两个文件都能正常使用这些函数和结构体。

方案2：用GCC隐藏属性处理大型共享函数 #

如果共享的静态函数代码量较大，不适合用static inline，可以把它们放到单独的工具.c文件，通过编译属性限制符号可见性：

1. 先写内部共享头文件：

// internal_shared.h
#ifndef INTERNAL_SHARED_H
#define INTERNAL_SHARED_H

// 声明共享函数和数据
extern int my_shared_func(int arg);
extern my_shared_struct g_shared_data;

#endif

2. 在shared_utils.c里实现这些函数，去掉static但加上隐藏属性：

#include "internal_shared.h"

// 让符号仅在当前模块可见
__attribute__((visibility("hidden")))
int my_shared_func(int arg) {
    // 原静态函数的逻辑
    return arg * 2;
}

__attribute__((visibility("hidden")))
my_shared_struct g_shared_data = {0};

3. 在拆分的两个业务.c文件里#include "internal_shared.h"，编译模块时把这三个.c文件都加入编译列表即可。

这种方式下，共享的符号只会在你的模块内部可见，不会和外部项目的同名符号冲突，同时拆分的业务文件可以正常共享这些逻辑。

针对你的几个疑问的明确解答 #

• 头文件声明static、.c定义非static的问题：绝对不能这么做！头文件里的static声明会让每个包含它的.c文件都生成独立的符号，而.c里的非static定义是全局符号，最终会触发重复定义错误，完全不可行。
• 是否要放弃拆分：完全没必要。Nginx官方的很多模块都是拆分多个.c文件实现的（比如ngx_http_core_module就有多个源文件），只要用对方法，拆分后可维护性会大幅提升，不会引入符号冲突。

Nginx模块特有的注意事项 #

• 把内部头文件放在你的模块专属目录下，不要放到Nginx的公共头目录，确保只有你的模块源文件会引用它。
• 在模块的config文件里，把所有拆分后的.c文件加到ngx_addon_srcs变量中，保证它们一起编译链接。

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