如何在 Cargo.toml 中静态 link sqlite3

How to link sqlite3 statically in Cargo.toml

我创建了一个 rust 应用程序,它使用来自 crates.io

sqlite crate

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

根据我阅读的 Cargo 文档,我的理解是 sqlite crate 本身是 link 静态编辑的,而不是它所依赖的 C 库。

在我自己的计算机上,我通过简单地将 sqlite3.dll 复制到我路径中的一个文件夹或相同的目录中解决了这个问题,cargo 在其中创建了我的可执行文件。

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

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

所以,我想通过静态 link 将此 DLL 添加到我的可执行文件中来避免这些复杂情况。

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

sqlite crate depends on the sqlite3-sys crate to provide the FFI towards SQLite. This crate in turn depends on the sqlite3-src crate,其中包含一个名为 bundle 的可选功能 - 如果您指定此功能,那么它会将 SQLite 的副本捆绑到您的 rust 二进制文件中。

为此,手动指定对这个包的依赖,如下所示:

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

执行此操作后,生成的二进制文件不应 link 朝向 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)