You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I've been trying to look into how the default target is set (I'm trying to get the core library building – #4). It seems like the default --target comes from host_triple(), which gets it from CFG_COMPILER_HOST_TRIPLE. Any idea if this is what we're looking to change?
We don't want to modify the Makefiles to ignore the host and generate AVR bindings - we want to add support to Rust so that we can call ./configure --target=avr-atmel-none and we get a compiler which targets AVR by default (not passing the target triple to rustc) which has a libcore compiled for AVR as well.
Currently I have a patch which fixes AVR support for compiler-rt, and adds support for 16-bit pointers to libcore. Will push when ready. Now merged, although compiling libcore leads to an LLVM assertion error.
we want to add support to Rust so that we can call ./configure --target=avr-atmel-none and we get a compiler which targets AVR by default (not passing the target triple to rustc)
I would prefer that, instead, the default target is the host, and that --target=avr-atmel-none is passed to cargo and rustc to build for AVR. Many crates need the host target in order to run their build.rs build script. Also, I would like to see AVR target support included in all releases of rustc for all platforms, and that can only happen if it is supported as a cross-compiler.
I am currently in the (long,slow) process of merging AVR-LLVM directly into the official LLVM repository. Once that is completed, Rust will simply have to update LLVM and it will be able to be used.
With regards to this issue, the only reason we can't use avr as the default target is because AVR-LLVM crashes while compiling libcore. This means that there's nothing physically stopping us from using AVR as the default target, except a bug that would've stopped us from compile libcore anyway.
The AVR-LLVM migration process will take a while, and so I plan on working on fixing AVR-LLVM issue 149 once that is completed.
@dylanmckay I'm not sure that there's much of a point to this. Rust defaults to the host system, and I'm 99.9999% sure that rustc will never run on AVR. Since our goal is to merge into upstream Rust, we'd never want to have such a behavior.
Activity
alexking commentedon May 13, 2015
So I've been trying to look into how the default target is set (I'm trying to get the core library building – #4). It seems like the default
--target
comes fromhost_triple()
, which gets it fromCFG_COMPILER_HOST_TRIPLE
. Any idea if this is what we're looking to change?dylanmckay commentedon May 13, 2015
If I recall correctly, if we pass
--target=avr-unknown
, LLVM also gets configured so thatavr-none
is the default target.The problem with this is that
compiler-rt
does not support AVR, so Makefile generation fails.[-]Set `avr-none` as the default target[/-][+]Support `avr-atmel-none` as the default target[/+]dylanmckay commentedon Aug 9, 2015
We don't want to modify the Makefiles to ignore the host and generate AVR bindings - we want to add support to Rust so that we can call
./configure --target=avr-atmel-none
and we get a compiler which targets AVR by default (not passing the target triple torustc
) which has alibcore
compiled for AVR as well.Currently I have a patch which fixes AVR support for compiler-rt, and adds support for 16-bit pointers toNow merged, although compiling libcore leads to an LLVM assertion error.libcore
. Will push when ready.core
crate for AVR #4dylanmckay commentedon Aug 17, 2015
This is currently blocked by AVR-LLVM issue #149
briansmith commentedon Oct 23, 2015
I would prefer that, instead, the default target is the host, and that --target=avr-atmel-none is passed to cargo and rustc to build for AVR. Many crates need the host target in order to run their
build.rs
build script. Also, I would like to see AVR target support included in all releases of rustc for all platforms, and that can only happen if it is supported as a cross-compiler.dylanmckay commentedon Oct 23, 2015
I have good news :)
I am currently in the (long,slow) process of merging AVR-LLVM directly into the official LLVM repository. Once that is completed, Rust will simply have to update LLVM and it will be able to be used.
With regards to this issue, the only reason we can't use
avr
as the default target is because AVR-LLVM crashes while compilinglibcore
. This means that there's nothing physically stopping us from using AVR as the default target, except a bug that would've stopped us from compilelibcore
anyway.The AVR-LLVM migration process will take a while, and so I plan on working on fixing AVR-LLVM issue 149 once that is completed.
[-]Support `avr-atmel-none` as the default target[/-][+]Support AVR as the default target[/+]mrdeveloperdude commentedon Aug 23, 2018
@dylanmckay Hi! I was randomly looking for llvm avr/arduino support when I came here. Taht is awesome! Any status update as of today (2018-08-23)?
dylanmckay commentedon Jan 20, 2019
libcore
now compiles fine.We need to get
compiler-builtins
working on AVR (#125) before AVR can be made the default target.shepmaster commentedon Jan 20, 2019
@dylanmckay I'm not sure that there's much of a point to this. Rust defaults to the host system, and I'm 99.9999% sure that rustc will never run on AVR. Since our goal is to merge into upstream Rust, we'd never want to have such a behavior.
dylanmckay commentedon Jan 20, 2019
Good point, I hadn't though of that - changing the default target to AVR could only ever be relevant in a rustc fork.