Understanding rust ABI (Dynamic Linking)

Hello,
i have an lib in my workspace and i want that cargo and rustc automatic link dynamic this lib.
So i compile my workspace and i have bin1.exe bin2.exe and lib1.rlib or lib1.dll. And when i delete the lib1.rlib/dll that the compiled binary show an missing rlib or dll message under windows/linux.

So cargo/rustc link automatic dynamic after compling the project.

BTW: How can i link an rlib/dll in my project as an compiled lib with standard rust function calling without c statements? So a complete Pure Rust ABI?

1 Like

Note that “Pure Rust ABI” doesn't exist. What does exist is “ABI of rustc compiler version x.y.z sha1 tag abcdef”. With any change to the compiler (and even the use of the exact same compiler with different options) leading to incompatible library.

And if you are Ok with using that (which means you are always rebuilding everything from scratch on any minor change of rustc version) then the solution is obvious: just use crate-type=dylib.

2 Likes

@khimru a pity that no pure rust ABI exist. I try to compile all my binarys with no external toolchain in path linked (hmm at the moment i develop only for the cli:)). Okay dylib is a cool tip,thx i will try and become problems.

I have inlcuded an lib in my workspace and put an simple hello world in the lib.rs. My main-binary has

Cargo.toml
testlib = { path = "../testlib" }
main.rs
use testlib::hello;

And in the main in call simply hello();

So no defining of crate_type makes an rlib with static link of the lib, cool standard. Compiling passed. When i set the crate_type to dylib and vargo build --release this errors appear:

error: cannot satisfy dependencies so `std` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `compiler_builtins` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `libc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `unwind` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `cfg_if` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `miniz_oxide` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `adler` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `hashbrown` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `std_detect` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_demangle` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `addr2line` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `gimli` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `object` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `memchr` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot link together two panic runtimes: panic_unwind and panic_abort

error: the crate `panic_unwind` requires panic strategy `unwind` which is incompatible with this crate's strategy of `abort`

when i use cargo +nightly compile functioned but the binary that link the dylib doesn't functioned and echo nothing. When i delete the use testlib::hello all functioned and with stable cargo build the same all goes right and all binarys don't have an dll-link inside.

???

strange the pure example from
https://stackoverflow.com/questions/75903098/dynamic-linking-between-crates/75903553#75903553
gives an binary that do nothing, when i not use crate_type=dylib an normal build with normal output will compile.

Ah okay it seems when i use

crate-type = ["dylib", "rlib"]

It compile without errors and linking to testlib with the hello function. Hmm cool no more binarys with empty functions.

But now when i delete the testlib.dll and delete all files except the dll it runs and give me the "Hello World" ouput, but this this should not happen why the dll is deleted and the binary doesnt can call the functions why the function is in the deleted dll. and i cannot find dy_lib.dll in the binary?

Hmmm, okay fully follow this:

and check all with ldd.exe

dylib =>
dy_lib.dll found
std-*****.dll not found

???

I must say i don't understand to use shared-libaries in my workdpace so that all binarys based on the dylib. So that when i use ldd.exe i became only dy_lib.dll and when i delete dy_lib.dll the dll-missing error appears.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.