The rust2rust ABI is considered unstable due to possible rearrangements of struct layouts by rustc. Generally speaking, it is considered that the rust2rust ABI is incompatible between different rustc, so can different builds of the same version of rustc guarantee ABI compatibility? Has rust officially guaranteed this?
I believe that this is true at the moment, but it isn't guaranteed to remain so in the future. Struct layout randomization, for example, might be added as an option to harden programs against certain classes of security vulnerability.
Struct layout randomization already is available on nightly with
@canndrew Do you have any opinion on this?
it is considered that the rust2rust ABI is incompatible between different rustc
Yes. Different versions of the compiler are vastly different to each other, including the Rust ABI
can different builds of the same version of rustc guarantee ABI compatibility?
No. Building the same program with the same build of the compiler even with the same flags is not guaranteed to be ABI compatible. In cases where they aren't in the same compiler run (basically whenever FFI is involved), it is, iirc, UB to do such a thing, and even if not it will randomly break and crash which is no fun.
In practice, rust builds are almost always reproducible so if you compile it twice it may turn out ok if all flags are identical, but YMMV. For instance, having the definition of a struct in a separate crate then passing it to a cdylib with a similar definition is almost certainly going to crash.
If this is something you're trying to do, just in case, I feel like I should bring up that you generally want to use an external crate, like
If I compile rust with RUSTFLAGS="-C prefer-dynamic", then I will see:
linux-vdso.so.1 (0x00007ffc690e0000) libstd-d787e53a290411e2.so => not found libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb1b0a43000) /lib64/ld-linux-x86-64.so.2 (0x00007fb1b1b4f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb1b082b000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb1b048d000)
Since the standard library can be dynamically linked, does it mean that the rustc ABI of the same version is compatible
The standard library is special because it's a part of the Rust toolchain and the compiler has special knowledge of it. Just because it works for
std doesn't guarantee it'll work for anything else.
Technically, it might work, but then you're relying on behaviour the compiler has explicitly said it doesn't have any guarantees for and will almost certain break in the future.