I actually don't know if this is really an issue in the current cargo-creusot setup..

Do we have a reproducible way of triggering this? I cannot reproduce this.

Not clear what has to be done here: it should not be possible to call Creusot in a setup where rustc_driver is not available. Assigning @arnaudgolfouse so that he determines what we could be done and the we can take some decisions.

It might actually have been fixed because a while ago I made it so we explicitly set +{toolchain} inside cargo creusot. It used to be that if you ran it on a random (stable) rust project you would get dyld errors.

The remaining problem is that if you do cargo install --path creusot-rustc, then you cannot run your creusot-rustc, and get the following error:

creusot-rustc: error while loading shared libraries: librustc_driver-9194d071d74e8e5f.so: cannot open shared object file: No such file or directory

which is really not nice.

The problem here is that we install creusot-rustc in the path for the default toolchain, which is likely different from the toolchain we link Creusot with.

What we would like somehow is to install creusot-rustc whereever cargo stores non-default toolchains (something like /.rustup/toolchains/<toolchain>/bin). But it's unclear whether we should be allowed to do that.

Anyway, it is pretty clear that the current practice of installing creusot-rustc in .cargo/bin is a bad idea. Only cargo-creusot should be installed at this place, because it does not rely on the rest of the toolchain. Then, cargo creusot can complain about the toolchain being used currently is not compatible with the current version of Creusot, or something like that.

I'm un-assigning @arnaudgolfouse and assigning @Lysxia, who seem to agree with this approach and is perhaps more used to work on the build system.

Here is an overview of what rustup does, which we could use as inspiration : https://rust-lang.github.io/rustup/concepts/proxies.html

Well the whole system is not designed to allow you to run creusot-rustc from outside of cargo creusot. We split creusot-rustc into cruesot-driver and creusot-rustc with creusot-rustc performing the same toolchain trick as cargo creusot.

What's surprising is that even though Rustc has some support for external tools, it seems like the ecosystem is not ready for that. How such tools built on top of rustc should be installed?

If we commit to the fact that creusot-rustc is only called from cargo-creusot, then we should not install it in the PATH.

What's surprising is that even though Rustc has some support for external tools, it seems like the ecosystem is not ready for that. How such tools built on top of rustc should be installed?

That's entirely unsupported. There are no stable apis to the compiler and no plans to stabilize any in the medium term future.

If we commit to the fact that creusot-rustc is only called from cargo-creusot, then we should not install it in the PATH.

I don't think that's possible, especially if we want to support cargo install. all that does is copy to ~/.cargo/bin and we need creusot-rustc to be a different binary from the cargo creusot one.

I think there's a line of pragmatism to balance here. Renaming it away from creusot-rustc should help prevent accidental usage. This is hardly the most problematic part of our ux.

Then /.cargo/bin/creusot-rustc-<toolchain> ?

sure, that seems easy enough to achieve and should make it harder to use by accident.

@Lysxia What do you think? Ready to do that?

That sounds good to me.

1. Install creusot-rustc as creusot-rustc-<toolchain>
2. Drop the hardcoded toolchain in cargo-creusot, using the active toolchain instead, with a nice error message if the corresponding creusot-rustc-<toolchain> does not exist.

Wait no, we can't drop the hardcoded toolchain! That will break the usage of creusot everywhere. It's very important for cargo creusot to hardcode the toolchain otherwise we cannot run on stable rust projects.

If project A uses a version of creusot built with toolchain X and project B uses another version of creusot built with toolchain Y, wouldn't you want to be able to specify the right version of the toolchain in each project?

Or are you saying that we also want the cargo-creusot binary to depend on the toolchain? In which case cargo-creusot should also be renamed cargo-creusot-<toolchain> and cargo-creusot would be a wrapper like rustup?

My main issue, and the one which led to this issue is that I want to do git clone my_stable_project && cargo creusot and have that work. We cannot build creusot-rustc for a stable toolchain at all. Additionally cargo install isn't really meant to installed versioned binaries, if we want to move to a world where we handle multiple versions of creusot simultaneously we'll probably need to write a rustup clone.

So, I guess the conclusion is to perform task 1. : "Install creusot-rustc as creusot-rustc-".

We do not support (yet) installing several versions of Creusot in the same account. This may be something useful, and may work in the future, but clearly not the priority.

Also, this means that we commit to the fact that the rustc version used by Creusot is not the same we are using for compiling. I hope there is not too many subtle semantic differences between rustc versions...

That difference is something we have to accept for now. We can publish which toolchain creusot uses but hardly impose it upon users.