LTO doesn't work with rust nightlies after 2020-04-29

[jschwe]

As reported in #7 building the rusty-demo with LTO doesn't work with rust nightlies newer than 2020-04-29. If this doesn't resolve by itself we should investigate what changed and if this requires any changes on our end in order to reenable LTO.

The error that gets printed when linking is the following:
error: failed to get bitcode from object file for LTO (Bitcode section not found in object file)

As a temporary workaround LTO was disabled in the release profile in #14

[tlambertz]

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.

[jschwe]

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.

[stlankes]

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

[jschwe]

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)

[stlankes]

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

[jschwe]

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

[stlankes]

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...

[jounathaen]

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

[stlankes]

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

[stlankes]

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