__attribute__((constructor))声明的函数在动态库加载时自动执行，作为.init_array段入口，要求全局可见、无参无返回值，优先级数值越小越早执行；对应清理函数用__attribute__((destructor))。
gcc编译时怎么声明动态库的初始化函数
动态库加载时自动执行的初始化函数，不是靠函数名约定，而是靠GCC的<strong>attribute</strong>((constructor))。这个属性告诉链接器：把这个函数注册为“.init_array”段中的入口，在dlopen()或程序启动时由运行时调用。
- 必须是全局可见函数（不能是
static），且无参数、无返回值（即void func(void)） - 多个
constructor函数按编译顺序（或<strong>attribute</strong>((constructor(priority)))）执行，priority值越小越早执行（通常101–65535安全） - 不要在这个函数里调用
dlsym()或依赖其他尚未完成初始化的共享库符号
__attribute__((constructor))
void my_init(void) {
// 初始化日志、全局句柄、信号处理等
}
动态库卸载前怎么写清理函数
对应初始化，清理函数用<strong>attribute</strong>((destructor))，在dlclose()或进程退出时触发。
- 同样要求
void func(void)签名，全局可见 - 若同时用了
constructor和destructor，它们不保证成对执行：比如dlclose()后又dlopen()，可能只调constructor一次但destructor没被调（取决于引用计数和glibc行为） - 避免在
destructor中释放已被free()的内存，或调用已卸载库的函数
__attribute__((destructor))
void my_fini(void) {
// 关闭文件描述符、释放malloc内存、取消信号注册等
}
为什么dlopen后constructor没执行
这是常见误解：默认情况下，dlopen("libxxx.so", RTLD_NOW) 不会触发constructor——除非该库此前未被加载过，且你没用RTLD_GLOBAL或符号已存在于主程序符号表中。
真正触发
constructor的是首次加载该SO的映射，而非每次dlopen如果主程序已链接了同名库（如通过
-lxxx），再dlopen同一路径，系统会复用已有实例，不重复初始化检查是否真的加载了新实例：
readelf -d libxxx.so | grep INIT_ARRAY，确认存在DT_INIT_ARRAY项用
LD_DEBUG=libs,init运行程序，观察动态链接器是否报告calling init: /path/libxxx.so不要依赖
constructor做“每次dlopen都重置状态”的事，那是设计错误；应改用显式导出的init_xxx()/cleanup_xxx()函数
跨平台兼容性要注意什么
<strong>attribute</strong>((constructor))是GCC/Clang特有，MSVC不支持。即使在Linux上，musl libc对destructor的调用时机也比glibc更严格（可能不调用，如果dlclose时引用计数未归零）。
- 在CMake中可加
check_c_compiler_flag判断支持性，避免静默失效 - 不要在
constructor里调用printf或malloc——早期初始化阶段堆和stdio可能未就绪；优先用write(2)和静态缓冲区 - 若需Windows兼容，改用DLL的
DllMain（DLL_PROCESS_ATTACH），但注意它禁止调用某些API（如LoadLibrary）
真正麻烦的不是写法，是误以为constructor/destructor能替代显式生命周期管理。它们适合“进程级单次设置”，不适合“每次dlopen/dlclose的资源租借”。
