Windows下cgo调用gorocksdb时DLL命名冲突问题咨询

这个问题我之前也碰到过，核心原因其实和RocksDB编译时的DLL内部命名绑定有关，不是gorocksdk的问题，而是Windows动态链接的机制导致的：

为什么会出现这个矛盾？ #

当你用vcpkg编译出rocksdb-shared.dll时，这个DLL的内部元数据里已经硬编码了它的原始文件名（rocksdb-shared.dll）——哪怕你把它重命名为librocksdb.dll，这个内部信息不会改变。

而MinGW的链接器（你通过msys64安装的gcc）在处理-lrocksdb参数时，会自动寻找librocksdb.dll，所以你重命名后能顺利完成编译链接。但到了运行阶段，Windows的动态链接器会读取可执行文件依赖的DLL的内部元数据，发现这个DLL的“本名”是rocksdb-shared.dll，于是就会去PATH里找这个原始文件名的文件，找不到就报错。

你可以用Windows自带的dumpbin工具验证这一点：

dumpbin /headers librocksdb.dll

在输出的File Header Values部分，找到Original filename字段，你会看到它还是rocksdb-shared.dll，这就是问题的根源。

为什么同时放两个文件能解决？ #

当你同时把rocksdb-shared.dll和librocksdb.dll放到PATH里时：

• 编译阶段：链接器找到librocksdb.dll完成链接；
• 运行阶段：Windows加载器根据DLL内部的原始名称，找到rocksdb-shared.dll并加载，程序就能正常跑起来。

更优雅的解决办法 #

除了复制两个文件，还有两种更干净的方式：

• 修改RocksDB编译输出名：在vcpkg编译rocksdb时，调整编译配置，让它直接输出librocksdb.dll（而不是rocksdb-shared.dll）。这样编译出来的DLL内部文件名就是librocksdb.dll，链接和运行时用同一个文件就行，不用折腾重命名。
• 切换到静态链接：如果不需要动态链接的灵活性，你可以编译RocksDB的静态库（rocksdb-static.lib），然后在CGO_LDFLAGS里指定链接静态库，这样整个依赖会被打包进Go可执行文件里，完全不用处理DLL的问题——代价是可执行文件体积会大一些。

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