Rust + SQLite - Configure rusqlite to use a local copy of SQLite

help
1

I am using rusqlite as a dependency in my toml file. It appears to make the associated folder size of a Rust program very large. Is it possible to have rusqlite utilize the local copy of SQLite on my Mac which I keep updated via Home Brew? If so, how do I connect it to my Rust program? If I just remove "bundled" from rusqlite will that do it? Any assistance will be appreciated.

[dependencies]
iced = { version = "0.14.0", features = ["advanced", "tokio"] }
rusqlite = { version = "0.38.0", features = ["bundled"] }
chrono = "0.4.44"
tokio = { version = "1.28.0", features = ["full"] }
2

Yes, removing bundled should make the build script try to find a library version.

IIRC it will attempt to run pkg-config to probe the location of sqlite's header and library files, so make sure you have that installed.

If you want the gory details, the how-to-find-the-library is found in libsqlite3-sys's build.rs.

1 Like
3

If I remove "bundled" any program that was setup with "bundled" in place will still have all the SQLite files in the folder? If so, is there a way to locate and delete or am I better off getting rusqlite to work with "bundled" removed and then copy over all of the .rs file logic to a new program? Thank you for the response.

4

Use cargo clean for clearing all the compilation artifacts (it's that "associated folder" if I understand you correctly).

In my experience, dependencies are just large in general regardless of whether they also build a C library,
but they become somewhat smaller if you build the program in release mode or apply other optimizations from https://github.com/johnthagen/min-sized-rust.

1 Like
5

I removed "bundled" from the rusqlite line in the toml. The program still works fine so it must be finding the version of SQLite on the Mac without any further configuration. Great. Cargo clean without any switches appears to delete every thing in the target directory. It shrinks the folder size down tremendously (to about 600 KB). A follow up question. Why does the program folder get to be so big over time. After working on a program, making changes and compiling the folder size will grow to 10's of gigabytes. What is happening that causes the folder size to grow?

6

If you want to verify that it's using the library you think, you can use $ otool -L <program>, which will list the binary's load-time dependencies.

One factor is that if you browse around in the target directory you'll notice that there are plenty of directories and files that end with hashes. IIRC these hashes represent build options and features (I think?). So if you keep changing build parameters, it may cause new hashes, and trigger new rebuilds of all dependencies that are affected by the changes.

I kept running out of disk space from all the huge target directories. Eventually I learned that one can configure a global build directory in ~/.cargo/config.toml, using:

[build]
target-dir = "/Users/blonk/tmp/bld/cargo"

The upside of this is that a single cargo clean wipes away all the target files for all projects. The downside is that one can't build two projects simultaneously.

Edit: I shouldn't imply that that is the only downside, using a global target directory will obviously cause you to need to completely rebuild all your projects after a cargo clean -- and there are others as well, though they are a little more esoteric. For instance, there are cases such as if you try to launch another build from a build script, you'll deadlock cargo. (Though to be fair, this is probably not something you should do anyway).

7

I attempted to install otool via cargo. During installation there was an error "no method named symbols found for enum mach_object::File in the current scope". The error number is E0599. This error occurs when a method is used on a type which does not implement it. Any ideas how to overcome this error and get otool installed?

8

I believe otool is a system tool, at least on my mac it resides in /usr/bin/otool. I guess I could have got it installed via Xcode or its command line tools at some point in history?

$ /usr/bin/otool -L ~/tmp/bld/cargo/debug/rusqlite-collision
/Users/blonk/tmp/bld/cargo/debug/rusqlite-collision:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)

One minor caveat is that I have an intel Mac -- but I would be surprised if otool isn't available for ARM Macs as well.

According to the docs, it looks like it's a repackaged llvm-otool, so if you don't have an otool, check if your package manager has some llvm package that includes llvm-otool.