Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot build the experimental LLVM 6.0 Compiler #97

Closed
jhwgh1968 opened this issue Apr 24, 2018 · 16 comments
Closed

Cannot build the experimental LLVM 6.0 Compiler #97

jhwgh1968 opened this issue Apr 24, 2018 · 16 comments
Assignees

Comments

@jhwgh1968
Copy link

jhwgh1968 commented Apr 24, 2018

I am actually interesting in solving issue #93... but I know I will want a more recent compiler than master, which is last November.

So I dug into getting the experimental branch of AVR Rust with LLVM 6.0 working (which is late January). The process was simple, I thought:

  1. Check out experimental branch source.
  2. Manually get patches in issue comments applied for LLVM 6.0 issues, by hacking git submodules to death
  3. Get it to compile using the directions in the README.

And, to my surprise, all that worked! But then:

cd hello_avr && cargo build --target=avr-unknown-unknown

Got me this response:

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target avr-unknown-unknown --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 101)
--- stderr
error: Could not create LLVM TargetMachine for triple: avr-unknown-unknown: No available targets are compatible with this triple.

Which is not the error I was expecting at all. And even if I take my extra LLVM patches out, it still does that.

I know this is experimental, but the issues opened here imply that more than one person has succeeded in getting this compiler built, and at least trying to compile Rust code. There appears to be some shared knowledge I am missing. What is that? And can the README.md be updated with it?

EDIT: I know it's not a path issue, because:

rustc --print target-list

Gets me the correct response:
[...]
armv7-unknown-linux-musleabihf
asmjs-unknown-emscripten
avr-unknown-unknown
i586-pc-windows-msvc
i586-unknown-linux-gnu
[...]

@shepmaster
Copy link
Member

Hey, that's wonderful you are interested in helping out! Basically, everything in the README should be the sum total of our knowledge — I update it so I don't have to remember things!

If you take a look at #91, that was the most recent work we did to upgrade, and I'm pretty sure a handful of us were able to compile with that. @dylanmckay, will you have time to rebase on Rust master anytime soon? Otherwise, I vote that we merge #91 as-is and then rebase again "soon" for good measure.

@shepmaster
Copy link
Member

For what it's worth, I rebased @dylanmckay's branch myself: https://github.com/shepmaster/rust/tree/avr-support-rust-2018-04-24-190a6c

I then built with:

mkdir debug-release
cd debug-release/
../configure   --enable-debug   --disable-docs   --enable-llvm-assertions   --enable-debug-assertions   --enable-optimize
python /absolute/path/to/avr-rust/x.py build

I was then able to use Xargo to build my blink program (which may have local changes):

rustup toolchain link avr-release-stage1 /absolute/path/to/avr-rust/debug-release/build/x86_64-apple-darwin/stage1/
rustup override set avr-release-stage1
XARGO_RUST_SRC=/absolute/path/to/avr-rust/src/ xargo build

@shepmaster
Copy link
Member

You can also check out the official blink program

@shepmaster
Copy link
Member

Ugh, ignore what I said, I think I was sleepy and compiling with the wrong thing. I'll try to check back in the morning after I've rebuilt things.

@shepmaster
Copy link
Member

shepmaster commented Apr 25, 2018

Ok, my hope is that you were right, that this is just a failure of mine to document a little detail 😉

I think the problem is that, by default, the AVR components of LLVM aren't built. I normally don't encounter this because I turn all the default components off for faster/smaller builds and set the experimental ones at the same time.

You can check to see if you have files like this in your build directory, my guess is you don't:

/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRCodeGen.a
/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRAsmParser.a
/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRDisassembler.a
/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRAsmPrinter.a
/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRDesc.a
/path/to/build/x86_64-apple-darwin/llvm/lib/libLLVMAVRInfo.a

You should be able to enable this with --experimental-targets=AVR:

 ../configure \
  --enable-debug \
  --disable-docs \
  --enable-llvm-assertions \
  --enable-debug-assertions \
  --enable-optimize \
  --enable-llvm-release-debuginfo \
  --experimental-targets=AVR

I've also added enable-llvm-release-debuginfo because debugging LLVM is useful!

I'm building this now and will check back in a while. If it works, I'll also force-push my branch to enable those by default.

@shepmaster
Copy link
Member

shepmaster commented Apr 25, 2018

Ok, I've pushed:

Edit 1 — I realized I should also update the LLVM fork to match with Rust. Stay tuned for more pushes with that.
Edit 2 — Now updated with LLVM

@jhwgh1968
Copy link
Author

I was wondering if it was LLVM's fault, based on that error message, but I had no clue how to fix it or what I was doing wrong.

Your theory seems plausible. I indeed do not see those archives in my build dir -- even though I swear I did see object files go by during the compile with names along the lines of backend/avr/AVRSpecialPass.o, which I why I was mystified. I guess they were never "used", and thus the linker just skipped them.

Anyway, I will be building off of your branch, with your directions, very soon. I'll make sure to let you know how it goes

@shepmaster
Copy link
Member

I'll make sure to let you know how it goes

Sound good. I'll update the README with the two new details. Hopefully @dylanmckay can chime in to say if we should go ahead and use this newly-rebased code or not.

@jhwgh1968
Copy link
Author

jhwgh1968 commented Apr 26, 2018

It compiled, and AVR is now a recognized target! 🎉

...but Xargo isn't quite happy with libcore, because of some language updates. Example:

error[E0225]: only auto traits can be used as additional traits in a trait object
   --> /opt/avr-rust/src/libcore/any.rs:133:27
    |
133 | impl fmt::Debug for Any + Send {
    |                           ^^^^ non-auto additional trait

I have figured out a couple of obvious ones, but others (such as the above) need a little more thought than I can provide tonight.

Thanks for all your help, @shepmaster!

@shepmaster
Copy link
Member

shepmaster commented Apr 26, 2018

isn't quite happy with libcore

Are you using the corresponding updated libcore? We can't compile the stock one.

@jhwgh1968
Copy link
Author

The moment I sat down to look at this today, I realized I didn't update the rust-src tree after installing the new compiler 😀

With that fixed, it works now. I'll be spending some time investigating Rust on AVR, and then take a crack at #93. I'll definitely update that issue when I'm ready to fully commit.

Thanks again for all your help, and the links. Closing this issue.

@shepmaster
Copy link
Member

I'll definitely update that issue when I'm ready to fully commit.

Feel free to do some half-baked thoughts in the issue; there's more lurkers than you know. Also, come hang out with us in the Gitter room

@dylanmckay
Copy link
Member

Hopefully @dylanmckay can chime in to say if we should go ahead and use this newly-rebased code or not.

Yeah that sounds good, I'll try get it building on my machine and then I should be able to push it.

@dylanmckay dylanmckay reopened this Jun 12, 2018
@dylanmckay dylanmckay self-assigned this Jun 12, 2018
@jhwgh1968
Copy link
Author

I see that there has been a recent rebase onto Rust master, and that @dylanmckay has things building with LLVM 7 and no custom patches. Good to see!

I would be willing to close this issue once the README is updated to include the missing configure script parameter @shepmaster identified.

@shepmaster
Copy link
Member

We've recently upgraded to LLVM 8 🎉 I'm going to close any bug that is reported against an older version of LLVM. If you are still having this issue with the LLVM-8 based code, please ping me and I can reopen the issue!

@shepmaster
Copy link
Member

And I updated the README with those details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants