Implement versioned library naming and rename libruststd back to libstd

[brson]

In 16dad84 we made the crate search based purely on metadata, so that we could rename libstd to libruststd.

As graydon pointed out, we are supposed to name our libraries lib[name]-[hash]-[version].so, so there's no way that libstd should cause a name collision.

Implement this naming convention, revert the above change and rename libruststd back to libstd.

[lht]

I will work on this. I like the idea of putting hash in library file name!

A few questions:
Should version of the soname be used when searching a library?
And should we follow the naming convention of putting version after ".so"?
Last, Should we verify if the hash is correct when linking?

[brson]

There are some very detailed comments about how Rust versioning is supposed to work in src/comp/back/link.rs that you should read.

I don't know anything about sonames so can't answer the first two questions (my guess is the answer to both is no - we're creating our own, platform-agnostic versioning mechanism). Maybe graydon has an opinion.

As to the last question, we don't need to verify the hash. This hash is just a hash of the exported metadata (everything in the #[link] attribute), and used to help differentiate the filename from other builds of the same library. I don't think we're using it for any security properties.

I'm a bit worried about how this will impact the build system since we won't be able to know the names of the libraries we're producing.

[lht]

Regarding to build system impact, how about break it into steps:

1. rustc --lib links output to libfoo.so. The canonical library name is still used when building, so it is perfectly predictable.
2. Add an option like rustc --hash which read the metadata of a library and compute a hash
3. make install invokes rustc --hash against each library and rename it when copying to target folder.

Or combine 2 and 3 by implementing something like rustc --install-lib.

[brson]

It seems to me like this would require installing a library in order to use it, which is pretty awkward. Regardless, I don't feel comfortable making a decision on this without @graydon's input.

[lht]

I think a library with name like libfoo.so is still okay to use directly. The metadata will be matched to decide if this is the correct version when resolving the use directive.

[brson]

But we'll link against libfoo.so, then install it, then libfoo.so doesn't exist.

[brson]

Graydon and I discussed this on IRC recently and he is of the opinion that we will be able to use wildcard rules as well as rules that run touch on dummy files but produce actual hashed libraries as side effects to make this work. Honestly, I am still skeptical but we can go ahead and implement this. The hardest part about this is definitely going to be updating the Rust build system.

[brson]

I was thinking about this more, and if the hashes are only based on version metadata (and possibly the version of dependencies) then the hash will be fairly stable - you'll just have to do some experimentation and edit the makefiles every time metadata changes.

[lht]

I'm more inclined graydon's idea of using glob to copy. I tried implement that in commit 7cdb18d.

The version number is quite stable for now, but it might be changing more often whenever we had minor and major updates after public release. And editing makefiles for updating filenames seems not good. Especially if there was a chain of dependent libraries.

Hash of dependencies is not implemented yet in this series.

[brson]

Oops, I didn't notice you had done so much work on this. Is it ready to merge?

[lht]

If you think what have done is okay, I would prefer to implement the rest (hash of dependencies) and then get the series merged together. I want to reduce the times of updating snapshots.

[brson]

OK, I will wait.

[graydon]

I think this bug is done now, no? was just tracking on pull req 1268 really?

[lht]

Yes, closing it.