OS no longer builds with rustc nightly 1.37.0: error: language item required, but not found: `eh_personality`

[mt-inside]

Hi,

First, many thanks for the series, it's amazing! I came to do the latest post today, but my OS no longer builds, presumably due to a compiler upgrade because nothing else has changed.

Compiler:
nightly-x86_64-apple-darwin unchanged - rustc 1.37.0-nightly (d3e2cec29 2019-06-26)

Error:
error: language item required, but not found: eh_personality``

The internet seems to think this is something to do with needing panic=abort? I have that in my target json file. I added it under [profile.dev] but that results in a different error:

error: linking with cc failed: exit code: 1

[AntoineSebert]

Hi @mt-inside

This behaviour is probably due to the nightly toolchain, which is unstable by nature. From time to time, a a nightly build my fail either on your main project or either on one of the dependencies because it is broken.

Two "solutions" : downgrade your nightly toolchain to a previous working version (using rustup); or wait for a future nightly build to solve the issue.

Hope it helps.

[phil-opp]

@mt-inside

First, many thanks for the series, it's amazing!

Thanks, I'm glad that you like it! :)

I came to do the latest post today, but my OS no longer builds, presumably due to a compiler upgrade because nothing else has changed.

That's strange. I just tried building it with the latest nightly and it worked without errors. We also have a CI job that tries to build the project with the latest nightly once a day. Here is the build with the exact nighly that you're using and it seems like it worked fine too: https://dev.azure.com/phil-opp/blog_os/_build/results?buildId=1698

So it seems like something in your code is slightly wrong. My guess is that maybe the panic=abort syntax in your target JSON is "panic": "abort" instead of the correct "panic-strategy": "abort"?

[mt-inside]

Hmm.

Yep, I've got
"panic-strategy": "abort", in my JSON

It won't build on stable, fails to parse bootloader = {version = "^0.5", features = ["map_physical_memory"]}

And new nightly (rustc 1.37.0-nightly (8ebd67e4e 2019-06-27)), same problem. There's no line number on the errors, is there anything I can do to dig further?

I've modified the code slightly from the blog but not a huge amount. It's here if anyone wants to try: https://github.com/mt-inside/mtos

I'll try to build it on a clean machine soon.

[phil-opp]

I tried your project and it compiled and ran fine for me using bootimage run. Have you tried a cargo clean before building?

Versions:

> rustc --version --verbose
rustc 1.37.0-nightly (8ebd67e4e 2019-06-27)
binary: rustc
commit-hash: 8ebd67e4ee394cad9441a801f2022724ae7e07db
commit-date: 2019-06-27
host: x86_64-unknown-linux-gnu
release: 1.37.0-nightly
LLVM version: 8.0

> cargo version --verbose
cargo 1.37.0-nightly (4c1fa54d1 2019-06-24)
release: 1.37.0
commit-hash: 4c1fa54d10f58d69ac9ff55be68e1b1c25ecb816
commit-date: 2019-06-24

> cargo xbuild --version
cargo-xbuild 0.5.12

> bootimage --version
bootimage 0.7.5

[mt-inside]

Ok, right, my mistake (obviously).

It'd been a while since I'd worked on this, and I forgot how to build it. bootimage build works fine, cargo build doesn't. I at least assumed cargo build was a subset; that it would build the library then bootimage would build the disk image around it.

Sorry for wasting your time :/ And thanks so much for taking the time to help me out!

[phil-opp]

No worries!

cargo build doesn't work because it tries to build your OS for your host system by default (e.g. as a macOS userspace executable). You need to pass --target x86_64-unknown-raw.json as argument to compile for a bare-metal target. This will still not work because cargo isn't able to build the sysroot (the core and compiler_builtins crates) on its own yet. So you need a tool like cargo-xbuild that builds the sysroot for you. So a working command that only builds the kernel should be cargo xbuild --target x86_64-unknown-raw.json.

I agree that this isn't really intuitive. For this reason I updated the blog recently to add support for more standard-like build commands. We still need cargo-xbuild for now, but we no longer need to pass the --target argument (since we override the default target) and instead of bootimage run we now can do cargo xrun. The same is true for testing. With rust-lang/rfcs#2663 merged, we will support the normal cargo build/cargo run/etc build commands, so that this confusion should go away.

---

I think we can close this issue. Let me know if you have other questions!