rustc need a way to generate versioned libraries

[semarie]

The traditionnal way for a package distribution system (think dpkg for Debian, or ports under OpenBSD) to copte with upgrade of shared libraries is to have libraries with versioned number like libfoo.so.MAJOR.MINOR.

The rational for OpenBSD could be found here: http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
It is designed for OpenBSD specifically, but it spots several issues and invalids solutions (like renaming the file after linking).

To resume the problem is (in the example of packaging rustc program):

• I want to package rustc under OpenBSD.
• rustc come with shared libs (libstd-4e7c5e5c.so for example).
• the library isn't versioned.
• so any futur upgrade of rustc package will break any compiled program that depends of libstd-4e7c5e5c.so (the file will change, some functions will changes, or be added or be removed).

Having versioned libraries permit the package distribution system to have, at the same time, multiple version of the same library (libstd-4e7c5e5c.so.1.0 and libstd-4e7c5e5c.so.3.1 for example), and having binaries that depend of differents versions.

[steveklabnik]

This is effectively part of rust-lang/rfcs#600 . Right now, you need to have the exact same SHA of the compiler to use a shared library, which is why it's done this way.

[huonw]

I'm not 100% sure this is dependent on having a stable ABI... AIUI, this issue more related to being able to match the file format packagers expect. That is, we do currently version libraries and binaries via the included hash (it should change as versions change), but packagers expect the file format to include the trailing version numbers instead. (Maybe some are flexible enough to work with alternate versioning schemes?)

Having a non-stable ABI means one cannot easily release patches for already released dynamic libraries, but I suspect we're not intending to do so for the compiler, given the short 6 week release schedule and it doesn't mean we can't be able to conform to the file format expected.

That said, the lack of a non-stable ABI means that release dynamically linked Rust programs is slightly pointless.

[semarie]

A simple way to accomodate could be to having a codegen option extra_extension that do similary job than extra_filename option, but after the extension ?

Packagers will be able to follow their file format without too much effort.

[cuviper]

If there's an ELF DT_SONAME tag, then there absolutely is an expectation of a stable ABI. Sometimes it's libfoo.so.MAJOR, but it could be any ABI stamp committed to long ago, like glibc's current libc.so.6. The usual setup then is a symlink chain libfoo.so (for linker -lfoo) -> $SONAME (for ld.so loading DT_NEEDED) -> the-real-libfoo.so, where the final name can take many forms.

Then on top of this you can have symbol versions, which lets you safely extend an SONAME and even replace old symbols with better ones. See Ulrich Drepper's How To Write Shared Libraries, especially section 3 on ABIs.

That's what library versioning is really about, IMO. But Rust doesn't set any SONAME right now anyway, and shouldn't bother until there's a stable ABI. And even then, the developer has to really commit to maintaining a stable interface themselves too.

[steveklabnik]

Triage: no movement.

[jieyouxu]

Triage: I'm going to close this issue on the rust-lang/rust issue tracker as unactionable because while this seems like a very reasonable feature request, this definitely needs an RFC to figure out a design that addresses the concerns.