Updates:

• "Fixed" CI build

CI failed for riscv64 because ripgrep failed to build - it appears unrelated to this PR (same error causing it to fail to build for buildbots: https://downloads.openwrt.org/snapshots/faillogs/riscv64_riscv64/packages/ripgrep/compile.txt).

Looks like jemallocator and/or jemalloc have to be updated to work on risc-v. I guess it is fine to drop ripgrep on riscv until upstream fixes it, if somebody have access to a risc-v system would be nice to track down why that constant is missing there...

@jefferyto looks ok to me... Also take notice that this (or at least the fix to PATH) should be backported to 23.05 as uwsgi is also broken there.

@lu-zero @Ansuel @jefferyto

A proposal.

Rust 1.73.0 is available, if you add this patch from gentoo, it's also buildable on/for musl 1.2.4 without openwrt/openwrt#12667 - but you need to add --set=target.$(RUSTC_TARGET_ARCH).crt-static=false to TARGET_CONFIGURE_ARGS if you are building on musl 1.2.4. I suggest there could be a Config.in file with option to enable it for build hosts that are musl, such as alpine or openwrt (both need some minor changes but build openwrt very well in the end, changes are needed for example for perl to build).

I have a sample here (without Config file) of rust 1.73.0 that is the first to build on musl 1.2.4 without compatibility patch from openwrt/openwrt#12667. That Makefile has mentioned configuration arg to succeed on musl build host.

@oskarirauta mhhh but the problem this pr fix would still be there correct?

@Ansuel Sure - my proposal fixes other things. But I wanted to point out some findings, such as that patch and it finally working on musl 1.2.4 (been waiting since musl 1.2.4 was out) and ofcourse, new version (actually also required for musl 1.2.4).

Just thought, that there is no point for me making a PR, if this is about to succeed soon as this is a bit different. And also, I've pointed out earlier the extra TARGET_CONFIGURE_ARGS necessary on musl build hosts, and it hasn't got any wind under it's wings, so better maybe to propose to people who are actually maintaining project. Proposal to put it as a configurable option - is something that I wanted to avoid, but from Makefile, it is very difficult to detect if host system is using musl. ldd --version prints it out, but it's not capturable, for example..

@oskarirauta actually no probably never used but we set config if musl is used instead of glibc. Check your .config file. I don't like using the configuration as we would face situation with glibc selected and rust musl option set. The option should be handled internally.

@Ansuel

I tried that. I just couldn't figure out the way.. Here's few:

dev@media:~# ldd --version
musl libc (x86_64)
Version 1.2.4
Dynamic Program Loader
Usage: ldd [options] [--] pathname

This cannot be parsed even in shell, for e.g. ldd --version | head -n 1 fails.
output is somehow different from normal stdout.

#!/bin/sh
musl_lib=$(ldd $(whereis ls | awk '{print $2}') | grep 'musl' | head -1 | cut -d ' ' -f1)
[ -n "$musl_lib" ] && musl_lib=true || musl_lib=false
echo lib: $musl_lib

Later works in shell... But in Makefile, if I try:
IS_MUSL:=$(ldd $(whereis ls | awk '{print $2}') | grep 'musl' | head -1 | cut -d ' ' -f1)
or ifneq ($(ldd $(whereis ls | awk '{print $2}') | grep 'musl' | head -1 | cut -d ' ' -f1),)
both attempts fail.

I'd be interested to see what you come up, it seems that quite few people have searched for answer to this. I also think it should be handled internally, just couldn't figure out the way. Checking libc link isn't reliable. libc.so isn't always link to ld-musl-x86_64.so or it cannot be counted that it is. For example on openwrt:

dev@media:/usr/src/openwrt# ls -l /lib/libc.so
-rwxr-xr-x 1 root root 3256328 Sep 30 23:06 /lib/libc.so

But I am very pleased that it was taken to consideration, finally I don't need to fork rust part of repo :)

#
# C Library
#
# CONFIG_LIBC_USE_GLIBC is not set
CONFIG_LIBC_USE_MUSL=y
# CONFIG_MUSL_DISABLE_CRYPT_SIZE_HACK is not set

not ok to use ldd to check this. you can use config

@Ansuel I think it is about host system.. What you use to build it. config does not know what is building it, it just knows the target.

That though does solve the problem for me, because I build musl, on musl, but it is deceiving.. But I think there is a reason why you haven't set that argument in the first place. And if there is no such reason, it could aswell be enabled for all..

ldd tells details about host system, especially if you really use system ldd, which is just a link to libc.so.

oh... so you want to use musl for host? well afaik that is totally not supported... last time i tried an alpine container to build stuff there were lots of problems and never manage to complete it in an usable state so I would first check and make that work.

Did the situation changed? Also instead of ldd can't you just parse the output of opening the libc .so?

Rust 1.73.0 is available, if you add this patch from gentoo, it's also buildable on/for musl 1.2.4

I think updating Rust and enabling it to build on musl hosts would be best handled in separate pull requests; this PR is probably a bit too big already.

Is there a new way to invoke compilation in subdir of $(PKG_BUILD_DIR) like MAKE_PATH in for normal compilation?.

This is useful for example gping rust package which using gping subdir of its source code : https://github.com/orf/gping/tree/master/gping .

Normally I am doing the following in the previous rust package (before this PR) :

define Build/Compile
	$(call Build/Compile/Cargo,gping)
endef

[EDIT]
Found the way :

define Build/Compile
	$(call Build/Compile/Cargo,$(PKG_BUILD_DIR)/gping)
endef

A bit weird for me to be honest.

please rebase to update package procs as well, then let's merge it?

Changes:

• Rebase on master
• Add PKG_BUILD_PARALLEL:=1 to procs
• Restore relative path argument to $(call Build/Compile/Cargo)
• Expand rustc bootstrap patch to cache downloads made by download.rs, e.g. for llvm
• Add commit to speed up Host/Install (gzip instead of xz, libdeflate-gzip instead of gzip)

Is there a new way to invoke compilation in subdir of $(PKG_BUILD_DIR) like MAKE_PATH in for normal compilation?.

Fixed 🙏

please rebase to update package procs as well, then let's merge it?

Done!

Hopefully ripgrep will have a new release soon, in the mean time either we distribute a snapshot or omit it from riscv

We will wait a few days until we will backport it to OpenWrt 23.05 branch, right? :)

@BKPepe I would create a pr just to check if the thing can be backported with no changes

Hopefully ripgrep will have a new release soon, in the mean time either we distribute a snapshot or omit it from riscv

Perhaps you can file an issue with ripgrep and/or jemallocator about riscv support?

We will wait a few days until we will backport it to OpenWrt 23.05 branch, right? :)

I have opened a PR (#22376), of course can wait a few days before merging.

Hopefully ripgrep will have a new release soon, in the mean time either we distribute a snapshot or omit it from riscv

Perhaps you can file an issue with ripgrep and/or jemallocator about riscv support?

it should work fine already, it is just the current ripgrep release is very old. Switching to the current master would make it work.

We will wait a few days until we will backport it to OpenWrt 23.05 branch, right? :)

I have opened a PR (#22376), of course can wait a few days before merging.