共享库中使用静态库时全局变量重复问题及解决方案问询

我有一个静态库中的函数f()，用于打印自身被调用次数，代码如下：

#include<stdio.h>
int a = 0;
void f() {
    printf("f at %p was invoked %d times\n", &f, ++a);
}

该静态库被用于共享库，共享库代码如下：

#include <stdio.h>
void f();

void hello() {
    f();
}

主程序同时调用f()和hello()，代码如下：

#include <stdio.h>
#include <dlfcn.h>
void f();

int main() {
    void *handle = dlopen("./libdynamic.so", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "%s\n", dlerror());
        return 1;
    }

    void (*hello)() = dlsym(handle, "hello");
    char *error;
    if ((error = dlerror()) != NULL) {
        fprintf(stderr, "%s\n", error);
        return 1;
    }

    hello();
    hello();
    f();
    f();
    dlclose(handle);
    return 0;
}

对应的Makefile：

all:
        gcc -c -fPIC static.c -o static.o
        gcc -shared -fPIC dynamic.c static.o -o libdynamic.so
        gcc main.c -o main static.o

运行输出显示函数f()和全局变量a存在两份副本，分别属于共享库和主程序。现咨询：

1. 能否让共享库与主程序共用同一全局变量a和函数f()？
2. 实际开发中是否遇到类似问题？
3. 最佳实践是什么？

1. 可以实现共享，两种常见方案 #

方案一：将公共代码做成共享库，统一依赖 #

把原静态库的代码编译成共享库，让主程序和动态共享库都链接这个公共共享库，这样进程内只会存在一份f()和a的副本。

修改后的Makefile：

all:
    # 编译公共代码为PIC目标文件
    gcc -c -fPIC static.c -o static.o
    # 生成公共共享库
    gcc -shared -fPIC static.o -o libstatic.so
    # 动态共享库链接公共共享库
    gcc -shared -fPIC dynamic.c -L. -lstatic -o libdynamic.so
    # 主程序链接公共共享库，并指定运行时搜索路径
    gcc main.c -o main -L. -lstatic -ldl -Wl,-rpath=.

运行主程序后，hello()和主程序直接调用的f()会共用同一个a变量，输出的地址和调用次数会保持一致。

方案二：让共享库复用主程序的符号 #

如果必须保留主程序静态链接公共代码的方式，可以通过动态加载选项让共享库使用主程序中的符号：

1. 修改主程序的dlopen调用，添加RTLD_GLOBAL选项，让主程序的全局符号对动态加载的共享库可见：

void *handle = dlopen("./libdynamic.so", RTLD_LAZY | RTLD_GLOBAL);

2. 修改Makefile，编译共享库时不链接static.o，让f()成为未定义符号，依赖主程序提供：

all:
    gcc -c -fPIC static.c -o static.o
    # 编译共享库时不链接static.o，保留f()为未定义符号
    gcc -shared -fPIC dynamic.c -o libdynamic.so
    # 主程序链接static.o，提供f()和a的实现
    gcc main.c -o main static.o -ldl

这种方式下，共享库会直接使用主程序中的f()和a副本，实现共用。

2. 实际开发中的类似场景 #

这类问题在以下场景中很常见：

• 插件化架构：主程序提供核心功能模块（如日志、配置），插件（动态共享库）需要复用这些模块的全局状态或函数，避免每个插件维护独立状态。
• 多共享库依赖公共模块：多个动态库依赖同一工具库时，若各自静态链接会导致多份符号副本，引发状态不一致（比如计数器、全局配置）。
• 热更新场景：动态加载的更新模块需要复用主程序的现有全局上下文，避免重新初始化状态。

3. 最佳实践 #

• 优先使用共享库承载公共代码：将公共函数、全局变量封装到独立共享库中，所有依赖组件统一链接该共享库，从根源上避免多副本问题。
• 严格控制符号可见性：默认使用-fvisibility=hidden编译，仅对需要共享的符号用__attribute__((visibility("default")))显式标记，减少符号冲突风险。
• 尽量避免全局变量：用单例模式、上下文参数传递替代全局变量，降低共享状态带来的耦合和意外问题。
• 谨慎使用RTLD_GLOBAL：仅在必须让共享库复用主程序符号时使用该选项，同时注意避免符号名冲突（比如不同模块使用同名全局变量）。
• 编译时检查符号重复：使用nm、objdump等工具检查目标文件/库的符号表，提前发现重复定义的符号。

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