file not found for module `montgomery`

Question

file not found for module `montgomery`

Opened this issue 7 years ago · 11 comments

This might be more user error than legitimate issue, but when trying to install aardwolf, I get this error:

` Compiling ring v0.11.0
Compiling r2d2-diesel v0.99.0
error[E0583]: file not found for module montgomery
--> /Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic/arithmetic.rs:15:9
|
15 | pub mod montgomery;
| ^^^^^^^^^^
|
= help: name the file either arithmetic/montgomery.rs or arithmetic/montgomery/mod.rs inside the directory "/Users/ghost/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.11.0/src/arithmetic"

error: aborting due to previous error

error: Could not compile ring.
warning: build failed, waiting for other jobs to finish...
error: build failed
`
However, arithmetic/montgomery.rs exists.

It looks like this is a known issue with a fix coming, but I don't have a solid enough grasp on Rust to fully understand what the issue is, exactly, or if there's a workaround in the meantime.

Answer 1 · 2018-01-08T01:59:22.000Z

That's because the ring library doesn't use a proper directory structure, and it broke with versions of rust nightly newer that December 21st. Use an older version of rust and you should be okay. The Rocket developer is already aware and making a solution

Answer 2 · 2018-01-08T02:02:21.000Z

thanks for the quick and simple explanation, @asonix!

Answer 3 · 2018-01-10T18:35:28.000Z

Wait... I thought we Pinned the rocket version?

Answer 4 · 2018-01-10T18:47:40.000Z

In fact we did...
file: rust-toolchain

I am going to apply this update to the INSTALL.MD

Answer 5 · 2018-01-13T05:04:26.000Z

Rocket works on the latest nightly again

Answer 6 · 2018-01-13T20:01:57.000Z

Thanks @asonix - still wondering if it makes sense to pin a known-working nightly.

Answer 7 · 2018-01-13T20:16:26.000Z

Yes, it still makes sense to pin the tool chain version. It'll prevent a lot of "Uh... It works for me"-type problems; specifically those caused by someone unwittingly trying to build the software without paying any attention to what version of the toolchain they are using. As for how Rocket suddenly got updated to a version that the pinned toolchain at the time stopped working, I'm not sure. It shouldn't have happened, because of the Cargo.lock file. The mostly likely explanation I can come up with is that we maybe didn't make the version specific enough in the Cargo.toml. Some important notes: [Cargo Manifest: The Version Field](https://doc.rust-lang.org/cargo/reference/ manifest.html#the-version-field) [Cargo Manifest: Specifying Dependencies](https://doc.rust-lang.org/cargo/ reference/specifying-dependencies.html)

…

On Saturday, January 13, 2018 2:01:58 PM CST BanjoFox wrote: Thanks @asonix - still wondering if it makes sense to pin a known-working nightly.

Answer 8 · 2018-01-14T00:36:39.000Z

Actually it -really- isn't a mystery.
It's because we have specific instructions in our INSTALL.md that used to state:

$ rustup toolchain install nightly

Therefore anyone running through the INSTALL.md, which is very well written (props!), they will install whatever is nightly for them at the time. That is why I made a direct commit to make it

$ rustup toolchain install nightly-2017-12-18

Answer 9 · 2018-01-14T13:13:48.000Z

Yes, but that's over-riden by the rust-toolchain file. It pins the version of the toolchain to what is specified in that file. As long as they're using cargo, cargo will automatically download, install, and use the pinned toolchain version, regardless of what version they have set as default or have installed.

…

On 1/13/2018 6:36 PM, BanjoFox wrote: Actually it -really- isn't a mystery. It's because we have specific instructions in our INSTALL.md that used to state: |$ rustup toolchain install nightly| Therefore anyone running through the INSTALL.md, which is very well written (props!), they will install whatever is nightly for them at the time. That is why I made a direct commit to make it |$ rustup toolchain install nightly-2017-12-18| — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#67 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEdfrZCpJnjNVNPVba8UxLfGgtzdL0Cbks5tKUwYgaJpZM4RV4HD>.

Answer 10 · 2018-02-04T02:51:47.000Z

So far I have been able to replicate this bug a few times.
Not sure what is going on, but when I -manually- set the nightly build (12-18-2017 I think?) in the README.md it seems to resolve the problems..

Not something to worry about now, but I will keep this in mind, and leave the issue open :)
This way people can reference it, and I will remember, in the event that people have problems.

Answer 11 · 2018-07-05T17:31:08.000Z

Newer versions of Rust Nightly seem to be working appropriately.
Closing this issue.