DyLib does not store the version information in the generated binary

[palazzo-train]

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?

[alexcrichton]

I unfortunately don't know much about versioning of DLLs or dynamic libraries in general, but I would suspect that the most Rust code wouldn't necessarily benefit from using it today. Without a stable ABI I suspect that the versions likely don't matter much, but I could be wrong!

[palazzo-train]

We are studying the possibility of migrating our production application from .NET C# to rust. As you can imagine it is too big to do, so our approach is to move some of the functions from C# to rust, by building rust DyLib and be imported by .NET C#.

The version of the DLL produced by rust will then be important.

Windows PE file allows you to store version information in the .exe or .dll. Visual Studio linker has the /version option to do that . https://msdn.microsoft.com/en-us/library/h88b7dc8.aspx

So it will be very nice if rustc and cargo also have such feature. I guess this feature can also help promoting the use of rust in the community (Just my opinion).

I think rust for the moment is Linux focused. In Linux, I don't know much about versioning neither. All I can think of is the SONAME option in gcc linker for versioning. But it seems not exactly the same thing.

Perhaps, the rust team could consider adding versioning support for Windows platform first?

[alexcrichton]

I haven't used C# that much before, but is the version required to load a dll? Rust is actually much more than Linux focused, Windows is very much a first-class citizen! You should be able to load a dynamic library from Rust into other languages via the LoadLibrary kernel32 API at least (having done so before myself).

Could you elaborate a bit more on what the versioning what be used for? Does C# require the DLL to mention a version or is that largely just a management tool?

[t-rapp]

My use-case for version information included in executables and libraries would be checking existing versions in the installer and including version information in debugging information (log files, about dialog, etc).

From the MSDN link posted above I guess this is not really the same as the /version option of Visual Studio linker. Instead it depends on including some VERSIONINFO resource file during linking:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa381058(v=vs.85).aspx

[s3krit]

Hi, Parity Ethereum would also benefit from this feature. Among other reasons, some anti-virus companies care about the VERSIONINFO resource in Windows executables for submitting binaries to their whitelisting programs (I know at least ESET does), and we have an open issue (openethereum/parity-ethereum#10598) where a particular version of our Windows binary causes false-positives.

[weihanglo]

See also

• Support soname for cdylibs #5045