Can we link the c libs as 'static' as possible? or make the 'static' link as default?

#1

I have been blocked by linking errors for so many times, and I’m not sure some crates which uses ffi with dynamic link is compitable with the libs installed. We can avoid this by linking c libs as static as possible.Trust me, It’s a big help to newbies.

2 Likes
#2

It sounds like this isn’t the fault of rustc per-se, it’s more that the *-sys crate might not be setting up linking properly.

I’ve done more FFI work than most rustaceans and even I find linking fiddly. A good solution would be to improve documentation around this sort of thing and publicize (or create if it doesn’t exist) well-respected resources on the subject. Then it’s “just” a case of fixing up any *-sys crates where linking doesn’t Just Work.

#3

Yeah, control over static-vs-dynamic is a struggle in every sys crate, and Cargo just doens’t have any good way to control it :frowning:

3 Likes
#4

Can we recommend the ffi developers use source code first, static libs second, dynamic libs last. The disadvantage is more source code and more network traffic, and every ffi crate developer may collect all the c deps. But the advantage is obvious, every user will save much time. Newbies will be easy. No compitable version issues.
(people’s time is more valuable than the storage and network).

1 Like
#5

Don’t forget that compiling from source in a build script means you need all the build tools on your machine. This is particularly annoying on Windows machines, where you hardly ever install cmake and tools like autotools or pkg-config are second-class citizens.

Compiling from source, especially for larger projects like libclang, can really have an impact on compile times.

I agree that compiling from source is the best way to go, but unfortunately it’s no silver bullet…

2 Likes
#6

I think we can do more about static link to solve this problem.
First we should have a site to store compiled c libs, may be something like this
site_platform_name_version.ext, (for example https://crates.io/linux_openssl_0.0.1.so)
then if someone can’t compile from source code,
in the build.rs, download the static lib from the site and store it at place like
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib
this way it will not need something like ‘autotools’ or ‘pkg-config’.
Ask the user to build or install the c libs should be the last way.

#7

I’ve written up some recommendations in my post about sys crates: https://kornel.ski/rust-sys-crate

While static is generally better than dynamic, there are some exceptions:

  • Linux distros hate bundled libraries and static linking, and Rust/Cargo in general is annoying for maintainers. Trying pkg-config first (except MUSL target) makes things easier.

  • on macOS programs are expected to dynamically link to libraries shipped with the OS (but not anything else, unless you’re making an app bundle).

On Windows building with the cc crate is the least bad option currently.

3 Likes