Standard Name for Libraries and binaries with versions

language design
1

Hello there,

Idea

I'm trying to make an application and distribute it as a binary with the standard library dynamic linked. It would be cool if the standard library and the cargo dynamic libraries presented the version they have. Like: libstd-1.55.0.so

currently I notice that for each update I made with rustup update, the standard library compiles to a different guid.

Advantages long run

  • A more stabilize naming system provides access to using multiple versions of the same library installed in the same system. Right now, If i want to distribute my rust library, it will come only as libfoo, and If a user tries to install libfoo 1.0 and libfoo 2.0, the names will collide, which will cause confusion on users as to why they, for example, can't install a specific software.

  • A more rubust naming system also provides a more standard way for multiple programs to use the same library. This is, in my vision, a way for us to install the standard rust library on users systems and expect multiple application to work with the same library. On the other hand, if every program is linked to a different library name (being all libstd stable for example) then users will end up with multiple libstd-[SOMETHING].so in their systems.

Naming Suggestions

I think that using lib[CrateName]-[Version].[NativeExtension] will be interresting as it also is easier for new users to understand which version of the library they have installed.

2

I notice that even though the standard library comes with libstd-[GUID].so, the guid is the same for every version of rust, sorry about that

3

The hash should be different for each rustc version, if not that is a bug.

(It is a hash of everything cargo uses to distinguish different crates and different compilation options of the same crate and not a guid by the way)

That is not enough. You can include two crates with the same name and version from different locations AFAIK. In addition if different rustc versions or compilation options are used, the library files are still not compatible. Only a hash would work. Cargo has an option to do this for building libstd, but it can't be done by default without breaking backwards compatibility. Having it as a stable option would be nice, but there is no way to predict the right filename to copy as the hash may arbitrarily change. (using a random number instead of a hash is a valid implementation, albeit an unlikely one due to breaking reproducability.)

1 Like
4

The hash should be different for each rustc version, if not that is a bug.

(It is a hash of everything cargo uses to distinguish different crates and different compilation options of the same crate and not a guid by the way)

Sorry I mean to say that If I installed version 1.55 stable on my computer I will have the same hash that another person that have the stable version on their computer.

Cargo has an option to do this for building libstd

is there any way to enable it for normal libraries?

5

Yes, because the file is identical.

It is an internal unstable option, so no, not on stable.

6

Hmm, got it. But is there a -Z option if I'm on nightly builds? for libraries I build?

7

It is an env var. Set __CARGO_DEFAULT_LIB_METADATA to any value. The exact hash will depend on this value.

Note that while it isn't gated on nightly, you must not expect it to be stable. I expect it to be removed if a stable option gets added for this.

8

Interesting to see. Thanks

9

On Linux the library versions are defined after the library name, so project would produce the default version libproject.so and with versions libproject.so.1.0.0. I think thats a way of implementing and not breaking the working libraries with the current default. On windows and macos we can implement the same thing in my opinion.

the libraries that are the default version are symlinks to the real libraries with versions. To make this work with new versions of cargo, I think it should create the symlinks as well:

libproject.so -> libproject.so.1.0.0
libproject.dll -> libproject.dll.1.0.0
libproject.dylib -> libproject.dylib.1.0.0
10

@bjorn3 do you happen to know how do I tell cargo to produce libNAME-hash.so instead of the normal libNAME.so?

also, when I specify a dependency with git instead of path, and it is a dylib, it just automatically falls to generate the hash. is that intentional?

shared = { git = "https://gitlab.com/somewhere"  } # does generate library hash
shared = { path = "../path/to/lib" } # doesn't generate library hash
11

Producing dylibs with a hash requires an unstable cargo option. See Rewrite build_sysroot.sh in rust · bjorn3/rustc_codegen_cranelift@ad971bb · GitHub if you are curious.

12

sorry, when the __CARGO_DEFAULT_LIB_METADATA=0 is setted, it puts the library inside the deps folder. I didn't see it.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.