The cross compilation instrcutions are confusing #265
Comments
The target configuration like what atomic sizes are supported, the pointer width, type alignments, ... Basically if a target doesn't have a target specification in rustc, you either have to write a target specification json file for it (or patch rustc to add a builtin target spec), or you have to pick a target rustc does support which is as close to the target you actually want to compile for as possible as any divergence can break the abi or cause compilation errors due to eg declaring features supported that aren't actually supported. If the C abi for your target doesn't match any of the existing architectures supported by rustc, you will have to modify rustc one way or another as rustc hard codes the abi calculation code. It doesn't allow specifying it in the target specification. |
|
Thanks, do you know how I should find out what to use for SuperH? Also I still don't know the answer to the thing about changing a setting and putting it back immediately |
|
Edit: Never mind, I was using the wrong GCC path I was using the first one instead of the second |
|
I'm getting another error (sorry): It looks like that symbol isn't in the shared library, did I build it wrong? I did |
|
Your command looks good. You can also add Are you sure you're using the latest commit in my gcc fork? |
I downloaded the GCC source from the GNU website as a tarball and applies the patches in the patches repo. I'll try building it from that repo instead |
|
Ah right. I forgot to update the patches repo recently, so there are a few patches missing. Sorry. |
|
I hope I'm not being too annoying but when I try to build your fork I get this error: It seems like this might be to do with SuperH not supporting the bfloat16 format? |
|
Yeah, maybe try commenting this |
|
I did a slightly different patch to set the size to 16 bits, then I got this: So I symlinked mips-linux-gnu-gcc to sh3eb-elf-gcc, but now I get this really long error It looks like something to do with it being 32-bit? It seems to be trying to use a 32-bit pointer as a 64-bit integer |
|
Yeah, indeed, it looks like it wants to cast a 32-bit pointer to a 64-bit integer. I'll attempt to fix this issue soon. |
|
I think the issue is here: rustc_codegen_gcc/src/context.rs Lines 169 to 170 in 1bbee3e |
|
How do I disable compilation of |
|
It also seems to be trying to use https://github.com/rust-lang/compiler-builtins, can it just use libgcc? |
Without rustc_codegen_gcc/build_sysroot/Cargo.toml Lines 9 to 12 in 1bbee3e
I guess you could try. compiler-builtins contains some missing from llvm's compiler-rt. It may or may not be the case that this also applies to libgcc. In any case libgcc or compiler-rt are still used as fallback for intrinsics missing from compiler-builtins. |
|
Oops, I meant with, not without Commenting that out gives me this: Commenting out the compiler builtins line too gives me this: Also commenting the patch lines: |
Is the core issue here. This patch is necessary for many crates in the standard library to compile, including compiler-builtins. Could you got back to the state where only alloc, std, proc_macro and test are commented out, build again and then post the contents of |
I see this: |
|
I think I know the issue. Normally liballoc enables the rustc-dep-of-std feature of compiler-builtins, but since liballoc isn't used, you need to explicitly enable it. You could replace the compiler-builtins dependency with |
|
That fixes that issue, thank you! I can compile Rust for SuperH now, at least for simple programs without std, but I had to patch some things etc. Maybe I can make some PRs for improving the documentation that I found confusing |
|
Sorry I was not there to follow this discussion. I'll still make a fix for the 32-bit pointer casts. |
|
Another issue I'm having when building with Cargo is this: It looks like this causes the issue: |
|
Yeah, unless you used a custom target specification with the correct architecture, rustc will produce a couple of object files with the wrong architecture outside of the control of the codegen backend. |
|
But the architecture isn't supported by LLVM so it won't recognise it |
|
That shouldn't matter. When rustc_codegen_gcc is used as codegen backend, LLVM isn't used anywhere and I believe all places in rustc where an object file is created without asking the codegen backend have a fallback for unknown architectures (except for dylibs, but you aren't creating a dylib anyway, right?) |
|
It still tries to use it for the ABI You said earlier
so would I have to modify rustc? |
|
Right, didn't think of the ABI calculations. Yeah, for those you need to modify rustc itself. It doesn't support defining ABI calculations in target spec json files. |
|
For now I made a wrapper script around the linker that rewrites the architecture field in the ELF header to set it to SuperH, which I think is safe as there's no actual code in it? It's not really a good solution but it lets me test it for now |
|
That should work.
Indeed. All object files produced directly by rustc contain symbol references and data in an architecture independent format only. |
|
I put a Dockerfile that builds this for SuperH here if anyone wants to use it as a rough guide either for SuperH or any other architecture: |
|
What could I change in rustc_codegen_gcc to help make anything simpler? |
|
I think the best way would be to upstream some of the patches I'm having to apply, which I'll try to make PRs for, and if there's anything where I'm not sure how to do it in a clean way I can ask for help with that, and then the documentation probably needs some improvement which I'll also try to PR Thanks for all the help so far, I would have struggled to work some of this out on my own |
|
@Heath123 thank you for all the patches you made in rust-casio-docker. I modified an older version of rust-casio-docker to successfully compile for the arc-elf32 target. Modifications made to rust-casio-docker:
You can test the compiled Rust code using QEMU. Follow kolerov's synopsys repository on how to build QEMU for ARC. Note that
I initially attempted to use LLVM since ARC is an experimental target but ran into issues documented in the Rust users forum. |
|
I updated the instructions and it should hopefully be much simpler now. Please reopen if you need more improvements. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I want to compile this for SuperH but I'm confused by these instructions. It says to change a setting in config.sh but then immediately change it to something else without running anything in between??? How is that different from just setting it to the second thing directly? Is there a step missing somewhere? Also when it says "having the same attributes" what does it mean? Which attributes?
The text was updated successfully, but these errors were encountered: