-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
rust: Initial commit - rust lang #13916
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just quick a look at this PR. It requires to have commit messages for patches, which you are adding,
The artifacts? The dist tarball is 500mb+ per triple target, and is
dependant on the host and target combo. There isn't anything to download.
You run the package in your source to create and handle the rust tool chain
for your specific build. Perhaps I'm not unstanding what you're asking.
The toolchain isn't used unless something is looking for it (like
suricata), at which point it'll call rust/host and will (create and)
install the rust toolchain. If the toolchain isn't in dl/, it creates the
dist before installing. If it is there, it just installs it.
…On Mon, Jan 11, 2021, 2:29 PM Josef Schlehofer ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lang/rust/Makefile
<#13916 (comment)>:
> +#
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=rust
+PKG_VERSION:=1.49.0
+PKG_RELEASE:=1
+PKG_LICENSE:=Apache-2.0 MIT
+PKG_LICENSE_FILES:=LICENSE-APACHE LICENSE-MIT
+
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/rust-lang/rust.git
+PKG_SOURCE_DATE:=2020-11-11
+#PKG_SOURCE_VERSION:=b2d115f6db5172c961dfeb50de15f35784dbc7c9
+#PKG_SOURCE_VERSION:=5a6a41e7847ff5f85a31b87431ce2af29c567f1d
+PKG_SOURCE_VERSION:=fa55f668e5ea5388ec98b9340969527252239151
+PKG_HASH:=skip <https://github.com/rust-lang/rust.git+PKG_SOURCE_DATE:=2020-11-11+#PKG_SOURCE_VERSION:=b2d115f6db5172c961dfeb50de15f35784dbc7c9+%23PKG_SOURCE_VERSION:=5a6a41e7847ff5f85a31b87431ce2af29c567f1d+PKG_SOURCE_VERSION:=fa55f668e5ea5388ec98b9340969527252239151+PKG_HASH:=skip>
Giving me the ability to quickly jump between milestones was/is something
I need to hold on to for the moment, but will be removed and SHA256 hashed
correctly before committing to the upstream.
Why you don't want to have CI passed in the meantime, so anyone can
download artifacts from this PR?
Right now, nobody knows that it even compiles.
See:
https://github.com/openwrt/packages/runs/1548152198?check_suite_focus=true#step:4:3730
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13916 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBY6JRFHJUPYWFDHIAQOUTSZNGSPANCNFSM4TVGXOBQ>
.
|
06518c0
to
079d58c
Compare
lang/rust/Config.in
Outdated
config RUST_OPTIMIZE | ||
bool "Build optimized rust code (--enable-optimize)" | ||
default n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this correspond to optimize = false
in config.toml? Setting that to false
isn't supported, turning it off by default seems like a bad idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are only a few things I set in the TOML via --set
having to do with the build system. (https://github.com/openwrt/packages/pull/13916/files#diff-000828b821201f172a6a3c1b97c5a89fd38753d46e7b0c11e475b7e61a99a24cR49)
These simply add (or not) the --
flag indicated (--enable-optimize
in this case) to the arguments passed to ./configure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well right, but it seems strange to me to expose this flag at all when there are a bunch of others you've left out. A compiler with optimize=false is basically useless, it will take a half hour just to compile the standard library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied the output from ./configure --help
to generate the list. Which did I miss? As we've discussed, I'm totally open to suggestions. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I don't think you need to expose every option by hand, there's a whole ton of them:
> grep -E '^(#[^ ]|\[)' config.toml.example
#profile = <none>
[llvm]
#download-ci-llvm = false
#skip-rebuild = false
#optimize = true
#thin-lto = false
#release-debuginfo = false
#assertions = false
#ccache = false
#ccache = "/path/to/ccache"
#version-check = true
#static-libstdcpp = false
#ninja = true
#targets = "AArch64;ARM;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86"
#experimental-targets = "AVR"
#link-jobs = 0
#link-shared = false
#version-suffix = "-rust-dev"
#clang-cl = '/path/to/clang-cl.exe'
#cflags = "-fextra-flag"
#cxxflags = "-fextra-flag"
#ldflags = "-Wl,extra-flag"
#use-libcxx = true
#use-linker = "lld"
#allow-old-toolchain = false
#polly = false
[build]
#doc-stage = 0
#build-stage = 1
#test-stage = 1
#dist-stage = 2
#install-stage = 2
#bench-stage = 2
#build = "x86_64-unknown-linux-gnu"
#host = ["x86_64-unknown-linux-gnu"]
#target = ["x86_64-unknown-linux-gnu"]
#build-dir = "build"
#cargo = "/path/to/bin/cargo"
#rustc = "/path/to/bin/rustc"
#rustfmt = "/path/to/bin/rustfmt"
#docs = true
#compiler-docs = false
#submodules = true
#fast-submodules = true
#gdb = "gdb"
#nodejs = "node"
#python = "python"
#locked-deps = false
#vendor = false
#full-bootstrap = false
#extended = false
#tools = ["cargo", "rls", "clippy", "rustfmt", "analysis", "src"]
#verbose = 0
#sanitizers = false
#profiler = false
#cargo-native-static = false
#low-priority = false
#configure-args = []
#local-rebuild = false
#print-step-timings = false
[install]
#prefix = "/usr/local"
#sysconfdir = "/etc"
#docdir = "share/doc/rust"
#bindir = "bin"
#libdir = "lib"
#mandir = "share/man"
#datadir = "share"
#infodir = "share/info"
#localstatedir = "/var/lib"
[rust]
#optimize = true
#debug = false
#download-rustc = false
#codegen-units = if incremental { 256 } else { 16 }
#codegen-units-std = 1
#debug-assertions = rust.debug (boolean)
#debug-assertions-std = rust.debug-assertions (boolean)
#debug-logging = rust.debug-assertions (boolean)
#debuginfo-level = 0
#debuginfo-level-rustc = 0
#debuginfo-level-std = 0
#debuginfo-level-tools = 0
#debuginfo-level-tests = 0
#run-dsymutil = false
#backtrace = true
#incremental = false
#parallel-compiler = false
#default-linker = "cc"
#channel = "dev"
#description = ""
#musl-root = "..."
#rpath = true
#verbose-tests = false
#optimize-tests = true
#codegen-tests = true
#ignore-git = true
#dist-src = false
#save-toolstates = "/path/to/toolstates.json"
#codegen-backends = ["llvm"]
#lld = false
#use-lld = false
#llvm-tools = false
#deny-warnings = true
#backtrace-on-ice = false
#verify-llvm-ir = false
#thin-lto-import-instr-limit = 100
#remap-debuginfo = false
#jemalloc = false
#test-compare-mode = false
#llvm-libunwind = 'no'
#control-flow-guard = false
#new-symbol-mangling = false
[target.x86_64-unknown-linux-gnu]
#cc = "cc"
#cxx = "c++"
#ar = "ar"
#ranlib = "ranlib"
#linker = "cc"
#llvm-config = "../path/to/llvm/root/bin/llvm-config"
#llvm-filecheck = "/path/to/FileCheck"
#android-ndk = "/path/to/ndk"
#sanitizers = false
#profiler = false
#crt-static = false
#musl-root = "..."
#musl-libdir = musl-root/lib
#wasi-root = "..."
#qemu-rootfs = "..."
[dist]
#sign-folder = "path/to/folder/to/sign"
#gpg-password-file = "path/to/gpg/password"
#upload-addr = "https://example.com/folder"
#src-tarball = true
#missing-tools = false
#compression-formats = ["gz", "xz"]
My point was that this option doesn't seem particularly useful to expose, and especially shouldn't be on by default.
lang/rust/Config.in
Outdated
config RUST_OPTIMIZE_LLVM | ||
bool "Build optimized LLVM (--enable-optimize-llvm)" | ||
default n |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what OpenWRT policies are for release vs debug builds, but the compiler is significantly slower without ThinLTO, you may want to consider turning it on by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then let's turn that on :D I was not going to set defaults for things I didn't know about unless I needed something to work and it didn't. This worked fine off by default, and I was waiting for those with more knowledge (ahem.. poke) to step in and tell me different :) I'll try it
lang/rust/Config.in
Outdated
config RUST_FULL_BOOTSTRAP | ||
bool "Full Bootstrap - Build three compilers instead of two (--enable-full-bootstrap)" | ||
default y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why enable this by default? It shouldn't be needed and it will make the build take half again as long. https://github.com/rust-lang/rust/blob/9503ea19edbf01b9435e80e17d60ce1b88390116/config.toml.example#L243-L248
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was my understanding that in order to get stage2 artifacts, the full bootstrap needed to happen (so it didn't stop at just stage0/1)? Remember, almost everyone using Rust-lang in an OpenWrt context will be cross-compiling and will need the stage2 artifacts that would be skipped without the full bootstrap. Did I misunderstand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think x.py should automatically rebuild stage2 if it needs to for cross compiling. I would try that first to see if it works.
Also, I'm slightly confused why you would need 3 compilers in the first place, I would expect a stage 2 compiler to work fine. That's what's distributed by rustup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x.py only gets call ONCE, during the initial compile. After that, the installation binaries I create are stored in an archive that is used instead of touching the rust source at all (unless the rust package version changes in the OpenWrt upstream). This means I only run x.py a single time for an install..
-rw-r--r-- 1 grommish grommish 520960752 Feb 11 00:57 rust-1.49.0-x86_64-unknown-linux-gnu_mips64-openwrt-linux-musl-install.tar.xz
That is an example of my toolchain installation files (basically, a one-off version of rustup I guess?) that are built during the first compile. Subsequent runs, even on a make clean
, sees that file, extracts it, runs the installs, and calls it a day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable, but I'm not sure how it's relevant. This is specifically about the rustc-dev component, which gets compiled with x.py at the same time as everything else. If you remove rustc-dev I think this option won't even be used either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm testing removing the -dev options as we speak to see if it breaks anything.. then, if not, I'll test without the full bootstrap
+pub fn target() -> Target { | ||
+ let mut base = super::linux_musl_base::opts(); | ||
+ base.cpu = "mips64r2".to_string(); | ||
+ base.features = "+mips64r2,+soft-float".to_string(); | ||
+ base.max_atomic_width = Some(64); | ||
+ Target { | ||
+ // LLVM doesn't recognize "muslabi64" yet. | ||
+ llvm_target: "mips64-unknown-linux-musl".to_string(), | ||
+ pointer_width: 64, | ||
+ data_layout: "E-m:e-i8:8:32-i16:16:32-i64:64-n32:64-S128".to_string(), | ||
+ arch: "mips64".to_string(), | ||
+ options: TargetOptions { endian: "big".to_string(), mcount: "_mcount".to_string(), ..base }, | ||
+ } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks useful to other distros too :) have you considered upstreaming it to rust-lang/rust?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why not, although it's just the built-in triple renamed and defined with a soft-float since the dynlinking is handles in the MUSL define.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any progress with upstreaming patches which you have for mips64, aarch64, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mips64-openwrt-linux-musl
was upstream'ed and merged into rust-lang
master back in February, 2022. It's the only actual hardware I have to test on, architect-wise.
As I continue with testing, or getting confirmation that the various tuples don't cause issues (armv5
still doesn't work, for example) and figuring out whether errors I see are because of OpenWrt build system, the tuple, the rust install, or the package itself (or some other interaction and/or combined situations). For example, I've had a request for the vaultwarden
package. I was seeing errors, I reported errors, and in the end, it was because the ring
crate (which is a common crypto crate from what I can tell) uses BoringSSL
, and BoringSSL
doesn't work for BigEndian archs (like mips64
) sigh. So chasing errors to ensure stability is a long, drawn out process.
And, even when everything seems to work, the end product may or may not work as intended. I had issues with suricata6
in which it would build with soft-float
flagged, enabled in the mips64-openwrt-linux-musl
tuple, but was SIGSEV erroring when I attempted to run it. Turns out, OpenWrt for mips64
didn't enable MIPS soft-float
emulation in the kernel.
So, if anyone wants to help me test an arch, verification can happen and I can upstream them. They are responsive enough.
lang/rust/rust_compile.mk
Outdated
define Host/Compile | ||
cd $(HOST_BUILD_DIR) && \ | ||
RUST_BACKTRACE=full $(PYTHON) x.py --config ./config.toml dist cargo extended \ | ||
library/std llvm-tools miri rust-dev rustc-dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why rust-dev
and rustc-dev
? That's the LLVM dynamic library and libraries for using rustc_private
; they shouldn't be needed unless you're using a custom rustc driver.
Hi @jyn514 ;) Honestly, I did the rust thing because I needed it, not because I know how to use it. Most of the comments I received while doing this went from "why?" to "can't be done". The suggestions/comments you've made I am certainly willing to entertain, as I KNOW there are better ways to optimize this. I do know that it WORKS, as is, so further testing would be needed.. I can't even beg people to identify their triples so I can patch them in :D and I've been too lazy to build out targets I don't have just to build a rust toolchain. As you mentioned, the first time takes a while.. I'll work through these suggestions and see what/if anything breaks. Thanks for the nudge! |
Would there be best practices for giving those options? Or any other you
can suggest to remove (or add?)
…On Mon, Feb 15, 2021 at 12:30 PM Joshua Nelson ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lang/rust/Config.in
<#13916 (comment)>:
> + config RUST_OPTIMIZE
+ bool "Build optimized rust code (--enable-optimize)"
+ default n
Oh, I don't think you need to expose every option by hand, there's a whole
ton of them:
> grep -E '^(#[^ ]|\[)' config.toml.example
#profile = <none>
[llvm]
#download-ci-llvm = false
#skip-rebuild = false
#optimize = true
#thin-lto = false
#release-debuginfo = false
#assertions = false
#ccache = false
#ccache = "/path/to/ccache"
#version-check = true
#static-libstdcpp = false
#ninja = true
#targets = "AArch64;ARM;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86"
#experimental-targets = "AVR"
#link-jobs = 0
#link-shared = false
#version-suffix = "-rust-dev"
#clang-cl = '/path/to/clang-cl.exe'
#cflags = "-fextra-flag"
#cxxflags = "-fextra-flag"
#ldflags = "-Wl,extra-flag"
#use-libcxx = true
#use-linker = "lld"
#allow-old-toolchain = false
#polly = false
[build]
#doc-stage = 0
#build-stage = 1
#test-stage = 1
#dist-stage = 2
#install-stage = 2
#bench-stage = 2
#build = "x86_64-unknown-linux-gnu"
#host = ["x86_64-unknown-linux-gnu"]
#target = ["x86_64-unknown-linux-gnu"]
#build-dir = "build"
#cargo = "/path/to/bin/cargo"
#rustc = "/path/to/bin/rustc"
#rustfmt = "/path/to/bin/rustfmt"
#docs = true
#compiler-docs = false
#submodules = true
#fast-submodules = true
#gdb = "gdb"
#nodejs = "node"
#python = "python"
#locked-deps = false
#vendor = false
#full-bootstrap = false
#extended = false
#tools = ["cargo", "rls", "clippy", "rustfmt", "analysis", "src"]
#verbose = 0
#sanitizers = false
#profiler = false
#cargo-native-static = false
#low-priority = false
#configure-args = []
#local-rebuild = false
#print-step-timings = false
[install]
#prefix = "/usr/local"
#sysconfdir = "/etc"
#docdir = "share/doc/rust"
#bindir = "bin"
#libdir = "lib"
#mandir = "share/man"
#datadir = "share"
#infodir = "share/info"
#localstatedir = "/var/lib"
[rust]
#optimize = true
#debug = false
#download-rustc = false
#codegen-units = if incremental { 256 } else { 16 }
#codegen-units-std = 1
#debug-assertions = rust.debug (boolean)
#debug-assertions-std = rust.debug-assertions (boolean)
#debug-logging = rust.debug-assertions (boolean)
#debuginfo-level = 0
#debuginfo-level-rustc = 0
#debuginfo-level-std = 0
#debuginfo-level-tools = 0
#debuginfo-level-tests = 0
#run-dsymutil = false
#backtrace = true
#incremental = false
#parallel-compiler = false
#default-linker = "cc"
#channel = "dev"
#description = ""
#musl-root = "..."
#rpath = true
#verbose-tests = false
#optimize-tests = true
#codegen-tests = true
#ignore-git = true
#dist-src = false
#save-toolstates = "/path/to/toolstates.json"
#codegen-backends = ["llvm"]
#lld = false
#use-lld = false
#llvm-tools = false
#deny-warnings = true
#backtrace-on-ice = false
#verify-llvm-ir = false
#thin-lto-import-instr-limit = 100
#remap-debuginfo = false
#jemalloc = false
#test-compare-mode = false
#llvm-libunwind = 'no'
#control-flow-guard = false
#new-symbol-mangling = false
[target.x86_64-unknown-linux-gnu]
#cc = "cc"
#cxx = "c++"
#ar = "ar"
#ranlib = "ranlib"
#linker = "cc"
#llvm-config = "../path/to/llvm/root/bin/llvm-config"
#llvm-filecheck = "/path/to/FileCheck"
#android-ndk = "/path/to/ndk"
#sanitizers = false
#profiler = false
#crt-static = false
#musl-root = "..."
#musl-libdir = musl-root/lib
#wasi-root = "..."
#qemu-rootfs = "..."
[dist]
#sign-folder = "path/to/folder/to/sign"
#gpg-password-file = "path/to/gpg/password"
#upload-addr = "https://example.com/folder"
#src-tarball = true
#missing-tools = false
#compression-formats = ["gz", "xz"]
My point was that this option doesn't seem particularly useful to expose,
and especially shouldn't be on by default.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13916 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBY6JRBRCWFXXBO7JXSPYLS7FK3NANCNFSM4TVGXOBQ>
.
|
I don't know what the purpose of the options are, I guess. What are people looking for when they customize builds? If it were me I would probably pick one set of options and use them for everyone, but I also have never maintained packages before 😆 |
Well, the biggest issues I have with this is that no one touches configure,
config.toml, or x.py directly. So options that might needed I want to have
available should the need arise for an individual. I can put common ones,
less common ones, and default ones. I just need to figure out which would
go where
…On Mon, Feb 15, 2021, 1:43 PM Joshua Nelson ***@***.***> wrote:
I don't know what the purpose of the options are, I guess. What are people
looking for when they customize builds? If it were me I would probably pick
one set of options and use them for everyone, but I also have never
maintained packages before 😆
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#13916 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBY6JR3NMNAG7FC3J66AJLS7FTM5ANCNFSM4TVGXOBQ>
.
|
8d4b80f
to
2b67d36
Compare
Updated PR to include mipsel-24kc |
compile tested for aarch64/rpi4 @ 3:23mins ( 2 core pentium ) -needed ccache ( host/apt ) other than that pretty smooth... thanks for the hard work |
I actually wanted to use the cccache is selectable in the settings, although I believe I also just set it for the builder if the build env ccache is set (https://github.com/openwrt/packages/pull/13916/files#diff-f2f5c684ef57dc9ef001c539fb9a97c8a66e2efe84b68985fa23b45f8f4a1dc4R30). |
Update to the build logic. The package now breaks the install binaries into the Host and Target components. This reduces on-disk footprint by roughly 360Mb for every extra target toolchain. It also allows for faster toolchain building when the Host toolchain is already in place. |
Will there be a tutorial how to put this on my device? |
you must add the packages llvm-rustc rust and rustc_host when you build openwrt. and keep in mind that some packages are made for the host, not packages that can be installed on the device |
don't understand how you guys can compile this, despite that there are errors in Makefile (fixable) like
I also get this
can't seems to understand from where is this coming |
I hope you use the makefile here I didn't get the error you found |
I'm on Ubuntu 22.04.1
sha256sum
|
don't use my changes. why don't you use here |
tried the rust-1.59 build, that is only host build (what I need) and failed after a long period of time with
I doubt that llvm makefile is failing for me, on the new makefile aproach edit: fixed -lz with |
@Grommish This PR is almost two years around now. I'd really love to get this into main-branch soon, like most people here. Is there any chance in supporting you in the final steps to take? |
for me, https://github.com/Itus-Shield/packages/commits/working is what works and I need, even if it's building everything and takes forever, guess that just updating to latest version will also work |
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
I updated to rust 1.64 here https://github.com/domo-iot/packages/tree/rust-update After a couple of fixes everything seems working as intended. |
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
There is still a bug in the rustc build since it seems to use the wrong dynamic linker when you link external libraries. |
Hi all, I don't know that we can expect Grommish to come back to this one anytime soon. He was using an Azure VM I loaned him for building and testing, and I've just had a look and the last time it was powered on was back in July... I've not seen or heard from him on IRC, either. Hope he's okay. Regardless, IMO, this PR is not a great way to get Rust in OpenWrt. The overall implementation here is... messy. That's not a reflection on Grommish - debugging toolchain build issues on Rust is not a lot of fun and the documentation is not great, it's impressive that he got this far - but long-term I don't think this is maintainable, and it's horribly inefficient at build-time. One major thing is, at last check, this PR builds an entire copy of LLVM and two copies of the rust toolchain, rather than starting with a prebuilt binary I did get partway through building out Rust support in a similar fashion to how golang support is laid out and functions - the rust and golang toolchain build systems follow fairly similar approaches, logically speaking, and the steps are broadly similar - but I haven't had the time or motivation to come back and finish it, not that I got super far. If you'd like to push this forward, I'd suggest looking at how the golang support has been implemented, and working to build something similar for Rust that involves slightly fewer hackarounds, is a bit more resilient to Rust version changes, and works with a That said I certainly don't speak for everyone and I can't speak for Grommish, whether he's here or not, so don't take my word as gospel 😅 |
We can try to upstream the other arch targets and have them in the tier-3 as the mips target is already. |
Heh... those targets aren't actually necessary either, FWIW. OpenWrt's various arch targets are already covered by existing upstream tuples, and we're building the whole toolchain ourselves anyway so we can use whatever config we like... |
Having them makes our lives a little simpler. once the json targets enter stable we could leverage upstream to install the host compiler and just compile std. The wrong dynamic linker for the musl targets is yet to be investigated though. Anybody using alpine can check what they are doing? |
I fixed the problem with the dynamic linker, @Grommish do you still have interest in completing it or may I take over? |
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
Ripgrep recursively searches directories for a regex pattern while respecting your gitignore Requires rust-lang (openwrt#13916) Signed-off-by: Donald Hoskins <grommish@gmail.com>
RFC - Rust Language integration into OpenWrt build environment.
This is a first try and will need to be gone over, corrected, fixed, etc.. I'm opening it up to the public for assistance.
Signed-off-by: Donald Hoskins grommish@gmail.com