rust-osdev / cargo-xbuild

Automatically cross-compiles the sysroot crates core, compiler_builtins, and alloc.
Apache License 2.0
260 stars 25 forks source link

error: failed to get bitcode from object file for LTO #69

Closed toku-sa-n closed 4 years ago

toku-sa-n commented 4 years ago

Hello. I use cargo xbuild to build my OS. Recently build failed with the following error message.

error: failed to get bitcode from object file for LTO (Bitcode section not found in object file)

My repository is this and cargo_settings.json is specified as the target. You can reproduce this by running make on the master branch. I also tried with phil-opp's .json file, but build failed. The only thing which made it possible to build is to disable lto ( lto = false in Cargo.toml) . cargo clean && cargo xbuild did not solve the problem. This is my CI history. You can see that the same commit succeeds and fails to build.

phil-opp commented 4 years ago

I never seen this error before, but it sounds more like a rust/cargo problem. Have you tried updating your nightly?

phil-opp commented 4 years ago

If it still occurs on the current nightly, it might be worth opening an issue in the https://github.com/rust-lang/rust repository.

ascjones commented 4 years ago

I'm currently investigating: this looks to be the culprit https://github.com/rust-lang/cargo/pull/8192.

Compiling with rlib enabled in Cargo.toml works, produces the following rustc flags:

-Cembed-bitcode=no

With rlib removed we get:

-C lto

Manually running rustc with -C lto replaced with -C linker-plugin-lto seems to work okay.

I'll look a bit further but that is what I've figured out so far.

phil-opp commented 4 years ago

@ascjones Thanks for investigating! I think you're right that this pull request caused it. We should definitely open a cargo issue with an example that reproduces this eror.

It seems like the rusty-hermit project has the same issue: https://github.com/hermitcore/rusty-hermit/issues/15, so it might make sense to cc the project developers in the issue.

toku-sa-n commented 4 years ago

I created a minimal example to reproduce: https://github.com/toku-sa-n/cargo_bug cargo xbuild should cause the error.

phil-opp commented 4 years ago

Thanks for the example @toku-sa-n. By bisecting rustc I found out that this error is caused by https://github.com/rust-lang/rust/pull/71528, which in combination with https://github.com/rust-lang/cargo/pull/8066 results in a more aggressive removal/ of bitcode for crates that have lto disabled. Since we compile the sysroot as a separate crate, this means that it gets compiled without bitcode because we don't have lto enabled for it.

I think the most simple fix is to always enable lto for sysroot builds. I will create a PR in a moment.

phil-opp commented 4 years ago

I created a fix at https://github.com/rust-osdev/cargo-xbuild/pull/70.

toku-sa-n commented 4 years ago

Still failing with cargo-xbuild 0.5.30 and rustc 1.45.0-nightly (9912925c2 2020-05-10). I tried cargo clean && cargo xbuild on my minimum example, but build failed with the same error. Is it better to send a issue on cargo project?

ascjones commented 4 years ago

Can confirm I also get the same error with the new version 0.5.30

phil-opp commented 4 years ago

Seems like I messed something up… I can also still reproduce the error. I'll take a look at it again right now.

phil-opp commented 4 years ago

Still investigating, but it seems like version 0.5.30 only fixed the breakage between nightlies 2020-04-30 and 2020-05-01. There seems to be another breakage between 2020-05-01 and current nightlies. Starting a new bisect run.

phil-opp commented 4 years ago

Regression is in https://github.com/rust-lang/rust/pull/71925, so it is likely https://github.com/rust-lang/cargo/pull/8192, as @ascjones suspected. I'm still not sure what the best fix is.

I think I will report this to the xargo project too since it also seems to affect them. Maybe they have an idea how to fix this.

phil-opp commented 4 years ago

I opened a xargo issue at https://github.com/japaric/xargo/issues/292.

I also found one possible fix: Set -Clinker-plugin-lto for the sysroot build via RUSTFLAGS. I will create a PR in a moment. Maybe you can help test it then?

phil-opp commented 4 years ago

@ascjones @toku-sa-n I created a new PR at #71. Maybe you could try whether it fixes the issue. You can install the new version through:

cargo install cargo-xbuild --git https://github.com/rust-osdev/cargo-xbuild.git --branch embed-bitcode  --debug --force
toku-sa-n commented 4 years ago

Thank you. Builds of both the minimum example and my OS succeed.

phil-opp commented 4 years ago

Great to hear that!

phil-opp commented 4 years ago

Fixed version released as v0.5.31.

ascjones commented 4 years ago

Works! Much appreciated :)

toku-sa-n commented 4 years ago

Sorry, very sorry, but the problem seems not to be solved. Actually cargo xbuild succeeded, but the output binary seems to have a defect. Building my OS did not succeed completely, with ld error:

ld: build/libramen_os.a: error adding symbols: file format not recognized

See CI log

phil-opp commented 4 years ago

@toku-sa-n It seems like this issue is not related to cargo-xbuild. It also occurs when using cargo's -Z build-std flag instead of cargo-xbuild. Try the following diff:

Click to show the diff ```diff diff --git a/Cargo.toml b/Cargo.toml index 26cf1bb..d9f1861 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -24,6 +24,7 @@ crate-type = ["staticlib"] [dependencies] spin = "0.5.2" +rlibc = "1.0.0" [dependencies.lazy_static] version = "1.4.0" diff --git a/Makefile b/Makefile index 478ffa6..dd58448 100644 --- a/Makefile +++ b/Makefile @@ -45,7 +45,7 @@ endif release:$(KERNEL_FILE) $(HEAD_FILE) $(LD_SRC)|$(BUILD_DIR) make clean - $(RUSTCC) xbuild --target-dir $(BUILD_DIR) --release + $(RUSTCC) build -Zbuild-std=core,alloc --target-dir $(BUILD_DIR) --release cp $(BUILD_DIR)/$(CARGO_JSON)/$@/$(shell basename $(LIB_FILE)) $(LIB_FILE) make @@ -53,7 +53,7 @@ $(KERNEL_FILE):$(LIB_FILE) $(LD_SRC)|$(BUILD_DIR) $(LD) $(LDFLAGS) -o $@ $< $(LIB_FILE): $(addprefix $(RUST_SRC_DIR)/, $(RUST_SRC))|$(BUILD_DIR) - $(RUSTCC) xbuild --target-dir $(BUILD_DIR) + $(RUSTCC) build -Zbuild-std=core,alloc --target-dir $(BUILD_DIR) cp $(BUILD_DIR)/$(CARGO_JSON)/debug/$(shell basename $(LIB_FILE)) $@ $(HEAD_FILE):$(HEAD_DEPENDS) diff --git a/src/lib.rs b/src/lib.rs index c67ceee..f817450 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -3,6 +3,8 @@ #![feature(start)] #![feature(naked_functions)] +extern crate rlibc; + mod asm; mod descriptor_table; mod interrupt; ```

So this isn't something that we can fix in the cargo-xbuild tool. I recommend creating a minimal example that uses -Z build-std instead of cargo-xbuild and then report it in the rust-lang/rust or rust-lang/cargo repository directly.

toku-sa-n commented 4 years ago

I see. Anyway, thank you for telling me.

phil-opp commented 4 years ago

I ran a bisect for your project with the above diff applied and the "file format not recognized" also appears with https://github.com/rust-lang/rust/commit/63d03779946a07d8c418a361278168a6d3a1f4d2.

phil-opp commented 4 years ago

The discussion in https://github.com/japaric/xargo/issues/292 showed that rustc bootstrap passes -Cembed-bitcode=yes instead of -Clinker-plugin-lto. I created https://github.com/rust-osdev/cargo-xbuild/pull/73 to switch cargo-xbuild to the same approach.