DyLib does not store the version information in the generated binary

When a Rust binary (executable or dylib) is built, the version information configured in Cargo.toml has no effect on the binary built, meaning the configured version is not stored inside the binary file.

In Linux, when I use readelf -V for a .so file, you can see the supported interface (SO Name) is stored under the Version definition section '.gnu.version_d' of the ELF file. For example, the output of readelf -V /lib/libnss_files-2.12.so:

Version definition section '.gnu.version_d' contains 2 entries:
   Addr: 0x0000000000001540  Offset: 0x001540  Link: 5 (.dynstr)
   000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libnss_files.so.2
   0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: GLIBC_PRIVATE

The /lib/libnss_files-2.12.so file is implementing interface version libnss_files.so.2

The readelf -V output for a Rust or Cargo generated dylib or executable has no such version information. The version config in Cargo.toml is only used by crates.io.

Moreover, Windows DLLs support storing the version information, not the SONAME interface version name like Linux. A cross-compiled Windows DLL also has no version info.

Is there any plan to utilize the OS's file versioning facility to store the version defined in Cargo in the generated binary?

The issue names Cargo.toml, generated Rust executables and dylibs, and platform tools such as readelf. Start by tracing how Cargo package version metadata relates to produced binaries on Linux and Windows, then define platform-specific completion criteria for storing and verifying that version information.