[Question] 有没有固定的下载地址可以得到最新的可用用于开发 riscv 的 musl gcc？感觉一直没有搞清楚

[unicornx]

RT-Thread Version

master

Hardware Type/Architectures

N/A

Develop Toolchain

Other

Describe the bug

以前都是参考的 .github/workflows/action_utest.yml 里写的链接。但是今天发现文件里的链接 https://github.com/RT-Thread/toolchains-ci/releases/download/v1.7/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2 并不能用来编译 app。

所以想知道官方的 URL。可以得到同时可以用于编译 kernel 和 app 的 musl gcc for riscv

而且最好是保持一个 latest 的 alias，就像现在 .github/workflows/action_utest.yml 里写的 https://github.com/RT-Thread/toolchains-ci/releases/download/v1.7/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2 一样。这样用户只要记住这个名字就好了。

Other additional context

No response

[BernardXiong]

@aozima 有ci build推送的链接吗？

[ZhaoCake]

我进行了一些尝试。

所用主要平台为qemu-virt64-riscv

---

首先是对于最新的musllibc，在它的bits/signal.h中没有SA_RESTORER的定义了，因此要进行编译，需要修改components/libc/compilers/common/include/sys/signal.h中的内容。

...
#ifdef RT_USING_MUSLLIBC
/* this is required for musl <signal.h> */
#ifndef _POSIX_SOURCE
#define _POSIX_SOURCE
#include <signal.h>
+#ifndef SA_RESTORER   
+// 或者其他修改方法
+#define SA_RESTORER 0x04000000
+#endif  
/* limiting influence of _POSIX_SOURCE */
#undef _POSIX_SOURCE

#else /* ndef _POSIX_SOURCE */
#include <signal.h>
#endif

#else
...

这样修改之后，能够完成编译过程。但链接部分依然有问题。

在当前ci的工具链中，riscv64-unknown-linux-musl/lib和sysroot下有kernel和debug相关的specs文件。但这在最新工具链中是没有的，这会导致无法链接，我尝试将其和其静态链接库libc_kernel.a移动到新的工具链中使用。但出现的问题是软硬浮点数链接（和其他）问题。从rtconfig.py中读到目标ABI是lp64，不太清楚这里为什么使用软浮点，应该是因为之前的工具链是一个软浮点数的工具链。我们可以通过-v来得到新旧两个工具链的编译配置。

# 新工具链
❯ $RTT_EXEC_PATH/riscv64-unknown-linux-musl-gcc -v
Using built-in specs.
COLLECT_GCC=/home/zhaocake/WorkSpace/temp/riscv/bin/riscv64-unknown-linux-musl-gcc
COLLECT_LTO_WRAPPER=/home/zhaocake/WorkSpace/temp/riscv/bin/../libexec/gcc/riscv64-unknown-linux-musl/14.2.0/lto-wrapper
Target: riscv64-unknown-linux-musl
Configured with: /home/runner/work/riscv-gnu-toolchain/riscv-gnu-toolchain/gcc/configure --target=riscv64-unknown-linux-musl --prefix=/mnt/riscv --with-sysroot=/mnt/riscv/sysroot --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././gcc --disable-default-pie --disable-multilib --with-abi=lp64d --with-arch=rv64gc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2    -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2    -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (GCC)

# 旧工具链
❯ ~/WorkSpace/Embeded/riscv64-linux-musl-for-rtt/bin/riscv64-unknown-linux-musl-gcc -v
Using built-in specs.
COLLECT_GCC=/home/zhaocake/WorkSpace/Embeded/riscv64-linux-musl-for-rtt/bin/riscv64-unknown-linux-musl-gcc
COLLECT_LTO_WRAPPER=/home/zhaocake/WorkSpace/Embeded/riscv64-linux-musl-for-rtt/bin/../libexec/gcc/riscv64-unknown-linux-musl/10.1.0/lto-wrapper
Target: riscv64-unknown-linux-musl
Configured with: /builds/alliance/risc-v-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-musl --prefix=/builds/alliance/risc-v-toolchain/install-native/ --with-sysroot=/builds/alliance/risc-v-toolchain/install-native//riscv64-unknown-linux-musl --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=/builds/alliance/risc-v-toolchain/riscv-gcc --disable-multilib --with-abi=lp64 --with-arch=rv64imac --with-tune=rocket 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imac -mabi=lp64 -D __riscv_soft_float' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imac -mabi=lp64 -D __riscv_soft_float'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)

可以看到现在所使用的这个工具链支持的架构应该是rv64imac，因此我疑惑于为什么在rtconfig.py中指定-march=rv64imafdc依然能够编译，并且-mabi=lp64 -D __riscv_soft_float意味着它不会使用FPU，那么在menuconfig中开启FPU是否真的生效了？我对此不理解，抱有合理怀疑。甚至在将rtconfig.py的mabi设为lp64d后，这个旧的工具链依然能够完成编译，但无法进行链接，同样是软硬件浮点错误，这意味着之前大约确实使用软浮点而没有使用FPU，这让我感到十分的困惑，知识浅薄不能断定。

---

回到如何支持新工具链的问题上。

删除‘components/libc/compilers/musl/SConscript’中的--specs编译选项后，将能够进行连接步骤，但由于缺乏之前的specs配置，无法正常链接。因此正考虑如何重新得到一份kernel.specs及其静态库。

---

最后关于下载最新工具链，汪老师要求一个保持lastest别名的工具链，没有找到现有的，我想在找到现在ci中工具链来源之前只能考虑维护一个编译配置或使用官方工具链。对于该ci中的工具链，如我前文所属，对于其是否真的使用了硬件浮点保持怀疑。

可以考虑在下载工具链时排序获取最新riscv linux musl gcc，提供一个下载脚本避免用户自己输入日期等信息。

#!/bin/bash

# 下载网页内容
wget -qO- https://mirror.nju.edu.cn/riscv-toolchains/release/riscv-collab/riscv-gnu-toolchain/LatestRelease/ |
  # 使用 grep 提取符合正则表达式的文件名
  grep -oP 'riscv64-musl-ubuntu-\d{2}\.\d{2}-gcc-nightly-\d{4}\.\d{2}\.\d{2}-nightly\.tar\.xz' |
  # 获取最新的文件名
  sort | tail -n 1 |
  # 使用 wget 下载最新的文件
  xargs -I {} wget https://mirror.nju.edu.cn/riscv-toolchains/release/riscv-collab/riscv-gnu-toolchain/LatestRelease/{}

---

工作尚未完成。进行comment的原因是怀疑之前的riscv64的qemu并没有成功使用FPU。包括在d1芯片、d1s芯片、cv18xx_risc-v中的rtconfig.py目标ABI都是lp64。

---

更新：

# 将`rtconfig.py`中的`-mabi=lp64`改为`-mabi=lp64d`。
# 将`components/libc/compilers/musl/SConscript`中的LINKFLAGS留空字符串。

LINK rtthread.elf
/home/zhaocake/WorkSpace/temp/riscv/bin/../lib/gcc/riscv64-unknown-linux-musl/14.2.0/../../../../riscv64-unknown-linux-musl/bin/ld: warning: rtthread.elf has a LOAD segment with RWX permissions
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(getenv.o): in function `getenv':
getenv.c:(.text.getenv+0x20): relocation truncated to fit: R_RISCV_HI20 against symbol `__environ' defined in .sbss.__environ section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(__environ.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(setenv.o): in function `__env_rm_add':
setenv.c:(.text.__env_rm_add+0x4): relocation truncated to fit: R_RISCV_HI20 against `env_alloced_n.0'
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(free.o): in function `get_meta':
free.c:(.text.get_meta+0x60): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_context' defined in .bss.__malloc_context section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(free.o): in function `nontrivial_free':
free.c:(.text.nontrivial_free+0x9c): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_size_classes' defined in .rodata.__malloc_size_classes section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(free.o): in function `__libc_free':
free.c:(.text.__libc_free+0x36): relocation truncated to fit: R_RISCV_HI20 against symbol `__libc' defined in .bss.__libc section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(libc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o): in function `__malloc_alloc_meta':
malloc.c:(.text.__malloc_alloc_meta+0x4): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_context' defined in .bss.__malloc_context section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o): in function `alloc_slot':
malloc.c:(.text.alloc_slot+0x6): relocation truncated to fit: R_RISCV_HI20 against symbol `__malloc_context' defined in .bss.__malloc_context section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(malloc.o): in function `__libc_malloc_impl':
malloc.c:(.text.__libc_malloc_impl+0x68): relocation truncated to fit: R_RISCV_HI20 against `debruijn32.0'
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(mprotect.o): in function `__mprotect':
mprotect.c:(.text.__mprotect+0x0): relocation truncated to fit: R_RISCV_HI20 against symbol `__libc' defined in .bss.__libc section in /home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(libc.o)
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(mq_notify.o): in function `start':
mq_notify.c:(.text.start+0x10): relocation truncated to fit: R_RISCV_HI20 against `zeros.0'
/home/zhaocake/WorkSpace/temp/riscv/bin/../sysroot/lib/libc.a(mq_notify.o): in function `mq_notify':
mq_notify.c:(.text.mq_notify+0xa4): additional relocation overflows omitted from the output
Memory region         Used Size  Region Size  %age Used
            SRAM:     1353688 B        14 MB      9.22%
collect2: error: ld returned 1 exit status

经过尝试，我认为想要在不更改项目代码的情况下改用新工具链可能是做不到的。由于该工具链缺少libc_kernel.a，因此在链接时会出现重定位截断错误的情况，造成这个问题的原因大可能由于使用了libc.a中的函数造成某些符号的地址超出了重定位的范围，在不知道老工具链中liibc_kernel.a的源码的情况下，无法搞出新的libc_kernel.a，那么就只可能尝试修改内存布局？（这方面不太了解）。

尝试libc_kernel.a加入到新的工具链的sysroot/lib下也是不可行的，如前文所述，这两个目标ABI是不一样的。

因此，即使找到了当前ci中工具链的新版本，如果没有对应的源码，依然不建议使用，毕竟如前文所述，对于ci中这个工具链是否真的启用了浮点数我保持合理的怀疑（实际上持否定态度），处理器带有fpu而不使用硬件浮点，这是不应该接受的。

[ZhaoCake]

因此，即使找到了当前ci中工具链的新版本，如果没有对应的源码，依然不建议使用，毕竟如前文所述，对于ci中这个工具链是否真的启用了浮点数我保持合理的怀疑（实际上持否定态度），处理器带有fpu而不使用硬件浮点，这是不应该接受的。

我完全不能够理解，但是这个旧工具链竟然确实是编译出了带有浮点指令的程序，尽管它只能指定lp64的ABI而不能指定lp64f与lp64d。这实在是一个太出乎意料的工具链，我真是完全不能够理解。现在缺乏编译器知识的我是足够困惑的。有没有大佬能点拨一下为什么一个-mabi=lp64的工具链，在编译时接收的ABI参数也是lp64，却能够编译出带有浮点指令的程序。

话说回来，我是通过移植whetstone浮点计算基准测试确定了这一点。在QEMU中运行这种基准测试并不是好的做法，但以下结果应该仍然能够反映出结论。

rt smart：使用这个ci中的musl工具链，编译器信息如上条评论。

关闭fpu并设置rtconfig.py中-march=rv64imac, 保持-mabi=lp64

Loops: 100000, Iterations: 1, Duration: 103 sec.
C Converted Double Precision Whetstones: 97.1 MIPS

开启fpu,改回rtconfig.py的-march=rv64ima, 保持-mabi=lp64

Loops: 100000, Iterations: 1, Duration: 39 sec.
C Converted Double Precision Whetstones: 256.4 MIPS

rt-thread standard: 使用的工具链是一个挺正常的工具链，

❯ $RTT_EXEC_PATH/riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/home/zhaocake/WorkSpace/Embeded/riscv64-unknown-elf-toolchain-for-rtt/bin/riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/home/zhaocake/WorkSpace/Embeded/riscv64-unknown-elf-toolchain-for-rtt/bin/../libexec/gcc/riscv64-unknown-elf/10.2.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: /scratch/jenkins/workspace/tpp-freedom-tools/tpp03--build-binary-packages--parameterized/obj/x86_64-linux-ubuntu14/build/riscv64-unknown-elf-gcc/riscv-gcc/configure --target=riscv64-unknown-elf --host=x86_64-linux-gnu --prefix=/scratch/jenkins/workspace/tpp-freedom-tools/tpp03--build-binary-packages--parameterized/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gcc-10.2.0-2020.12.8-x86_64-linux-ubuntu14 --with-pkgversion='SiFive GCC-Metal 10.2.0-2020.12.8' --with-bugurl=https://github.com/sifive/freedom-tools/issues --disable-shared --disable-threads --enable-languages=c,c++ --enable-tls --with-newlib --with-sysroot=/scratch/jenkins/workspace/tpp-freedom-tools/tpp03--build-binary-packages--parameterized/obj/x86_64-linux-ubuntu14/install/riscv64-unknown-elf-gcc-10.2.0-2020.12.8-x86_64-linux-ubuntu14/riscv64-unknown-elf --with-native-system-header-dir=/include --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-tm-clone-registry --src=../riscv-gcc --with-system-zlib --enable-checking=yes --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc CFLAGS=-O2 CXXFLAGS=-O2 'CFLAGS_FOR_TARGET=-Os -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os -mcmodel=medany'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (SiFive GCC-Metal 10.2.0-2020.12.8)

可以看到它的--with-abi=lp64d。

关闭fpu并修改rtconfig.py中-march=rv64imac， -mabi=lp64

Loops: 100000, Iterations: 1, Duration: 64 sec.
C Converted Double Precision Whetstones: 156.2 MIPS

开启fpu并修改rtconfig.py中-march=rv64imafdc, -mabi=lp64d。（如果不修改mabi理所当然地会报错，所以这个musl工具链令我头疼）

Loops: 100000, Iterations: 1, Duration: 26 sec.
C Converted Double Precision Whetstones: 384.6 MIPS

对比结果显然得出结论，该ci中的musl库工具链能够在lp64的目标ABI下编译出能够运行的带有浮点指令的程序。

我应该单独提一个issue关于这个问题。

[unicornx]

@ZhaoCake 请问您是负责做工具链的吗？我提这个问题的原因是因为我发现用 .github/workflows/action_utest.yml 里写的 musl toolchain 链接 (https://github.com/RT-Thread/toolchains-ci/releases/download/v1.7/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2) 可以用于编译 kernel，但不能用来编译 app。然后我问 RTT 的同事，userapps 那边 zhujiale 和 heyuanjie 说这个链接的版本旧了。给了我另一个链接，然后就好用了，编译 kernel 和 user mode app 都没有问题。

所以我的本意是希望 RTT 那边是否可以发布一个统一的链接，或者把 https://github.com/RT-Thread/toolchains-ci/releases/download/v1.7/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2 这个链接更新到最新的版本就好。

我看您研究了很多，不知道是不是 RTT 那边已经解决了这些问题了吗？

其实我只是想要 RTT 公布一个统一的最新版本的链接给社区用。

[ZhaoCake]

@unicornx

所以我的本意是希望 RTT 那边是否可以发布一个统一的链接，或者把 https://github.com/RT-Thread/toolchains-ci/releases/download/v1.7/riscv64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2 这个链接更新到最新的版本就好。

您好，我是在试图使用gdb调试qemu启动的rt smart时遇到由于工具链版本过低导致无法使用gdb调试的情况。这可以通过开启一个docker或者降低我系统版本库的方式解决。不过我看到您提出的这个issue所以尝试使用新工具链，不过显然出现了问题。

请问您可以提供新版本工具链的获取方式吗？或者更新在ci utest中。十分感谢。

[unicornx]

请问您可以提供新版本工具链的获取方式吗？或者更新在ci utest中。十分感谢。

https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2

ci test 那个应该有专人维护我就不去随便动了。
我觉得最好按照我这个 issue 的建议统一到最新的以后就好了，也就是说我们只要记住形如 ”xxxx_latest.tar.bz2“ 这样的链接就好了，否则这种一大串数字的看着就很奇怪。

[BernardXiong]

看下来有些迷糊，首先对rt-smart用的musl gcc工具链做些澄清，免得混淆了：

• rt-smart使用的musl gcc工具链并不是一个标准的musl gcc版本，所以无法从musl原版 + gcc原始版本构建出一份rt-smart musl gcc工具链出来；
  • 核心点是，rt-smart使用的musl是一份修改后的libc；而且这份musl libc编译出的libc_kernal.a是给内核使用的，用户态使用的则是libc.a；（所以有了kernel spec的定制）
  • gcc相关的代码应该都未进行修改，是原版的gcc工具链。核心点是musl libc上；
• rt-thread github用的ci musl gcc工具链仅用于ci build看护，所以是一个老的版本，不是新版本；
• 新版本是rt-smart内部git ci推送的，有固定的下载地址：
  • riscv版本：https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2
  • aarch64版本：https://download.rt-thread.org/download/rt-smart/toolchains/aarch64-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2
  • 上面两个版本都是最新推送版本，所以也是非正式发布版本；理论上也包括Windows版本的工具链；

[a1012112796]

核心点是，rt-smart使用的musl是一份修改后的libc；而且这份musl libc编译出的libc_kernal.a是给内核使用的，用户态使用的则是libc.a；（所以有了kernel spec的定制）

所以建议最好还是把名称中的目标core 直接从 linux 改为 rtsmart, 这样便于区分。例如 aarch64-rtsmart-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2

[ZhaoCake]

感谢提供的新工具链，刚刚尝试了，已经可以用新工具链的gdb启动调试。不过这个工具链构建的时候依赖于python2.7，这在版本较新的Linux系统中是没有的，通过动态库软链接的方式可以对原系统影响尽量小地引入python2.7的依赖。解决方法如下，后续的文档或许可以用得到。

报错内容：

 》 $RTT_EXEC_PATH/riscv64-unknown-linux-musl-gdb rtthread.elf
/home/zhaocake/WorkSpace/Embeded/riscv64gc-linux-musl-for-rtsmart/bin/riscv64-unknown-linux-musl-gdb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

考虑使用pyenv安装一个python2.7到虚拟环境中，然后把这个环境下的动态链接库链接到/usr/lib或/usr/local/lib即可。

pyenv install 2.7.18  # pyenv的安装各个系统可能不同故略去
ln -s ~/.pyenv/versions/2.7.18/lib/libpython2.7.so.1.0 /usr/local/lib

然后可以正常启动gdb进行调试。

此方法适用于本身不带python2.7的系统。

[unicornx]

感谢提供的新工具链，刚刚尝试了，已经可以用新工具链的gdb启动调试。

@ZhaoCake 请问你用的是

• 我提供的：https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2

OR

• 熊大提供的 https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2

目前看起来似乎应该用熊大提供的。

[ZhaoCake]

@unicornx

请问你用的是

先前使用的是您提供的工具链，刚才使用了熊大提供的工具链，也同样需要libpython2.7.so.1.0。

但从构建日期上来看，汪老师提供的 (https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2) 工具链更新，不知道是不是出于稳定性的考量没有定向到latest。

https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2

  ❯❯ /home/zhaocake/Downloads/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu/bin : ./riscv64-unknown-linux-musl-gcc -v
Using built-in specs.
COLLECT_GCC=./riscv64-unknown-linux-musl-gcc
COLLECT_LTO_WRAPPER=/home/zhaocake/Downloads/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu/bin/../libexec/gcc/riscv64-unknown-linux-musl/10.1.0/lto-wrapper
Target: riscv64-unknown-linux-musl
Configured with: /builds/alliance/risc-v-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-musl --prefix=/builds/alliance/risc-v-toolchain/install-native/ --with-sysroot=/builds/alliance/risc-v-toolchain/install-native//riscv64-unknown-linux-musl --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=/builds/alliance/risc-v-toolchain/riscv-gcc --disable-multilib --with-abi=lp64 --with-arch=rv64imafdc --with-tune=rocket 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imafdc -mabi=lp64' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imafdc -mabi=lp64'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
build date: Oct 20 2023 16:21:07
build sha: 8a397096c1ef8f0e71f75edb27d7fc6996785206
build job: 547555
build pipeline: 203957

https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2

  ❯❯ /home/zhaocake/WorkSpace/Embeded : $RTT_EXEC_PATH/riscv64-unknown-linux-musl-gcc -v
Using built-in specs.
COLLECT_GCC=/home/zhaocake/WorkSpace/Embeded/riscv64gc-linux-musl-for-rtsmart/bin/riscv64-unknown-linux-musl-gcc
COLLECT_LTO_WRAPPER=/home/zhaocake/WorkSpace/Embeded/riscv64gc-linux-musl-for-rtsmart/bin/../libexec/gcc/riscv64-unknown-linux-musl/10.1.0/lto-wrapper
Target: riscv64-unknown-linux-musl
Configured with: /builds/alliance/risc-v-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-musl --prefix=/builds/alliance/risc-v-toolchain/install-native/ --with-sysroot=/builds/alliance/risc-v-toolchain/install-native//riscv64-unknown-linux-musl --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++ --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=/builds/alliance/risc-v-toolchain/riscv-gcc --disable-multilib --with-abi=lp64 --with-arch=rv64imafdc --with-tune=rocket 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imafdc -mabi=lp64' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medany -march=rv64imafdc -mabi=lp64'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
build date: May 13 2024 23:51:27
build sha: 8a397096c1ef8f0e71f75edb27d7fc6996785206
build job: 601285
build pipeline: 222725

[unicornx]

@BernardXiong 尝试了你说的 ci 推送的有固定地址的 riscv版本：https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_latest.tar.bz2。发现编译内核还行，但是编译 app 然后放到 ext4 文件系统下运行就会 crash

但是用 https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2 这个就可以编译 app。

正如 @ZhaoCake 分析的，

但从构建日期上来看，汪老师提供的 (https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_x86_64-pc-linux-gnu_222725-8a397096c1.tar.bz2) 工具链更新，不知道是不是出于稳定性的考量没有定向到latest。

所以那个 latest 的版本是不是还不是最稳定的？要不要更新一下？

[BernardXiong]

原来都是这样啊，我去check下哈

[BernardXiong]

还有Windows版本的工具链链接：

https://download.rt-thread.org/download/rt-smart/toolchains/aarch64-linux-musleabi_for_i686-w64-mingw32_latest.zip
https://download.rt-thread.org/download/rt-smart/toolchains/riscv64gc-linux-musleabi_for_i686-w64-mingw32_latest.zip