<jannic[m]>
That's while building build.rs, right?
<dirbaio[m]>
Check you have nothing overriding the linker for "all ARM", I've seen some examples/templates do that to set the linker for the embedded target, assuming the host is x86
<dirbaio[m]>
Hmm but that wouldn't set it to the aarch64-linux one
<dirbaio[m]>
Maybe you have some .cargo/config.toml in some parent folder affecting things?
<jannic[m]>
I tried it out on a freshly installed aarch64-unknown-linux-gnu vserver: I don't see -C linker=aarch64-linux-gnu-gcc in any of the rustc invocations.
<jannic[m]>
That was on ubuntu 24.04, rust installed using rustup.
<thejpster[m]>
also, I think the issue with infinite recursion in compiler-builtins might have been fixed - although most people probably didn't notice as it only seemed to affect SPARC and WASM, and maybe other CPUs that don't have hardware multipliers.
<thejpster[m]>
(I think I need a new computer - repeatedly rebuilding rustc on a 10 year old quad-core Core-i5 4590 is starting to get me down)
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]>
<dirbaio[m]> "Maybe you have some .cargo/..." <- I'm going to search more :)
<korken89[m]>
I just got Linux running on my Snapdragon X based laptop, so I guess this is quite uncharted territory. 😅 The interesting thing is that it builds fine on x86 so I think you are right about something overriding all ARM.
<i509vcb[m]>
korken89[m]: That's a weird error since I've been able to build stuff fine on aarch64 Linux
<korken89[m]>
Yeah, I'm quite confused tbh
<korken89[m]>
Maybe it's NixOS related as well
<i509vcb[m]>
Yeah I'd probably think NixOS is the first place I'd check
<i509vcb[m]>
Everything builds fine on Fedora for me
<korken89[m]>
It's also only this one project that had issues. I devved on the rysty probe for hours without issues. Something is sneaky
<dirbaio[m]>
Nixos is well known for resulting in broken rust installs :D
<korken89[m]>
s/rysty/rusty/
<korken89[m]>
Oh noes 😅
<dirbaio[m]>
You installed it from rustup, at least?
<korken89[m]>
Yeah
<korken89[m]>
Worst case it's just to remove crate after crate in the repo until one hits the truth
<JamesMunns[m]>
can you put your code up in a gist or github repo?
<dirbaio[m]>
hashing bitcoin addresses? :P
<JamesMunns[m]>
you don't just need to import the crate, you need to import the trait in the rust file
<JamesMunns[m]>
And yeah, for what it's worth, this room is for embedded systems, like microcontrollers. #rust:matrix.org is I think a general Rust room.
<omani[m]>
^ btw `rustup update` fixed this for me.
<omani[m]>
* for me. with a new version of rust-analyzer.
huayra1[m] has joined #rust-embedded
<huayra1[m]>
i really, *really* want rust in my kernel that i am developing. it's a fork of xv6 that i have worked in for months. it has DLang support because it was seamless, but i have tried like 4 times to integrate rust, to no avail. my requirements:
<huayra1[m]>
- no rustup
<huayra1[m]>
- (preferrably) no nightly features
<huayra1[m]>
i can work my way up from a wrapper around C
<nandnor[m]>
OK if you can get rid of all of your variadic functions then thats one step closer (btw this is the feature I am talking about that requires nightly #![feature(c_variadic)] ) but probably other roadblocks as well
<JamesMunns[m]>
it covers a lot of this
<huayra1[m]>
JamesMunns[m]: yes but it jumps right into rustup
<huayra1[m]>
if my toolchain can compile i686, it should.
<JamesMunns[m]>
wait, why no rustup? It's a nice tool.
<huayra1[m]>
the downstream users would need it
<huayra1[m]>
and it fetches a lot of internet stuff for a toolchain for every user
<JamesMunns[m]>
if they are compiling the kernel?
<huayra1[m]>
xv6 is pretty inseperable from the kernel
<JamesMunns[m]>
I mean, maybe I just don't track the planned use case. You can always make your own toolchain distribution or whatever, it's just generally not pleasant.
<huayra1[m]>
rxv64 doesn't compile on modern rust toolchains either
<JamesMunns[m]>
gotcha, maybe just suggesting you could use rustup until you have it working, then package your own toolchain with deps pre-vendored I guess?
<JamesMunns[m]>
dunno how far along you are with your integration work.
<huayra1[m]>
added only a few thousand lines to it
<JamesMunns[m]>
(rustup supports adding custom built toolchains as well)
<huayra1[m]>
it's not a production thing or anything but anyone even merely wanting to test it already needs: c compiler, d compiler, linker, qemu, ar, ranlib, gmake, and now a 500mb download that is guaranteed to be needed
<huayra1[m]>
nobody casually has an i686-unknown-elf target lying around on their machine
<JamesMunns[m]>
I suppose you know your user's need better than I do!
<JamesMunns[m]>
Sounds like an interesting challenge.
<huayra1[m]>
not to mention support for i686 rustup targets seems to be limited: no nightly and no "complete" toolchain, just "minimal".
<dirbaio[m]>
rustc can compile for any supported target, always
<huayra1[m]>
would you like to see the project perhaps?
<huayra1[m]>
dirbaio[m]: through *what* flag? --target?
<dirbaio[m]>
--target, yep
<dirbaio[m]>
popular targets include a prebuilt stdlib shipped through rustup.
<dirbaio[m]>
less popular targets don't, in that case you have to build the stdlib yourself. Cargo has builtin support for this, it requires just adding the -Zbuild-std flag.