LTO doesn't work with rust nightlies after 2020-04-29 about hermit-rs HOT 10 CLOSED

This is likely related to Don't force rustc to do codegen for LTO builds, which makes cargo more lto-aware to speed up builds. But I am not sure where the problem lies exactly.

from hermit-rs.

This was merged only 3 days ago, so it probably isn't that specific PR (I'm assuming rust nightlies are built from master). However there seem to be a lot of related PRs concerning LTO and changing how it works in the past weeks.

Edit: I think rust-lang/rust#71528 might have something to with this, which was also merged on the 29th of April. According to the description

Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's -Clto bitcode
loading to load rlibs produced with -Clinker-plugin-lto. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.

The PR indicates that no object files should be generated, while the error indicates otherwise. This might be related to libhermit-rs being built by a build script instead of directly via cargo. But I don't really know enough about rusts build system and cargo to dig deeper.

from hermit-rs.

The problem is solved. At least it works on my test system.

from hermit-rs.

It's still broken for me.
Tested on windows with rustc 1.45.0-nightly (ad4bc3323 2020-06-01) and commit c68ef8e and also on ad0e4d2.
Both rusty_demo and netbench fail to compile in release mode with lto enabled with the error: error: failed to get bitcode from object file for LTO (Bitcode section not found in object file)

from hermit-rs.

I fixed it, but we have still an issue by building application with LTO support. The linker encodes the wrong OS ABI. See also rust-lang/rust#73606

from hermit-rs.

Looking at the PR, this only works for thin LTO, right? Commit 66325e6 suggests that using full lto lto = true would still broken, correct?

from hermit-rs.

Yes, but this is also a bug in the Linker Plugin. I am able to link and to run with lto = true, but the optimization is too aggressive. I was able to see, that the linker assumes that global data is partly constant, which isn't the case. I have to look in the details...

from hermit-rs.

The -C linker-plugin-lto (or somethin simmilar) has to be set. e.g. int the .cargo/config

from hermit-rs.

Hm, can you set -C linker-plugin-lto only for x86_64-unknown-hermit and releaseversion?

from hermit-rs.

I close this issue. The readme describes, how LTO can be activated.

from hermit-rs.