Open palazzo-train opened 8 years ago
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!
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?
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?
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
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 (https://github.com/paritytech/parity-ethereum/issues/10598) where a particular version of our Windows binary causes false-positives.
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 ofreadelf -V /lib/libnss_files-2.12.so
:The
/lib/libnss_files-2.12.so
file is implementing interface versionlibnss_files.so.2
The
readelf -V
output for a Rust or Cargo generated dylib or executable has no such version information. The version config inCargo.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?