如何在 Cargo.toml 中静态链接 sqlite3



我创建了一个 rust 应用程序,它使用 crates.io 中的 sqlite crate

我只是按原样使用这个板条箱,当我用cargo run运行我的应用程序时,我确实得到了我想要的。但是,似乎我的应用程序现在依赖于sqlite3.dll,这需要在我的路径中。

从我阅读的 Cargo 文档中,我的理解是 sqlite 板条箱本身是静态链接的,而不是它所依赖的 C 库。

在我自己的计算机上,我只需将 sqlite3.dll 复制到我路径中的文件夹或 cargo 创建我的可执行文件的同一目录中即可解决此问题。

但是,我意识到这不适用于任何 sqlite3.dll 文件,但它适用于我在.multirust文件夹深处找到的文件。

此外,当我将此应用程序提供给其他人时,我还必须确保 DLL 也在那里。

因此,我想通过将此 DLL 静态链接到我的可执行文件来避免这些复杂性。

有没有办法在不深入研究自定义构建脚本的情况下静态地告诉 Cargo 链接这个 C 库?

sqlite crate 依赖于 sqlite3-sys crate 来为 SQLite 提供 FFI。这个 crate 反过来依赖于 sqlite3-src crate,其中包括一个名为bundle的可选功能 - 如果您指定此功能,那么它会将 SQLite 的副本捆绑到您的 rust 二进制文件中。

为此,请手动指定对此包的依赖关系,如下所示:

[dependencies.sqlite3-src]
version="0.2"
features=["bundled"]

执行此操作后,生成的二进制文件不应链接到sqlite3.dll。我无法在Windows上测试它,但它适用于Linux:

$ ldd target/debug/so_sqlite
linux-vdso.so.1 =>  (0x00007ffcf7972000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1781fb9000)
librt.so.1 => /lib64/librt.so.1 (0x00007f1781db1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1781b95000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f178197f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f17815b2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f17824d3000)

最新更新