Support riscv64-linux-x86_64 toolchain instead of riscv64-linux-musl-x86_64?

[overheat]

There is a riscv64-linux-x86_64 toolchain(gnu, not musl) under host-tools.

Could we support riscv64-linux-x86_64 toolchain?

[gtxzsxxk]

If you are referring to the buildroot, it will be able to use any c library or toolchain as long as they have rv64 and buildroot support, after the buildroot merged into mainline, which is coming soon.

[onkoe]

@gtxzsxxk I'm sorry to mention you, but has this issue progressed in the past few months? musl has only been a mild annoyance, but it's annoying enough to keep me from getting more Duos for a bit. 😅

[gtxzsxxk]

@onkoe

Hello! Please refer to

https://github.com/gtxzsxxk/duo-buildroot/discussions/4#discussioncomment-7687961

https://github.com/gtxzsxxk/duo-buildroot/discussions/4#discussioncomment-7689369

Hope these explain.

And could you please tell me why people do not like musl? I have no idea on this phenomenon. When submitting patches to buildroot, they also show unwelcome to musl. But if no musl, the toolchain couldn't be compiled with glibc since the upstream haven't fixed some bugs on t-head's optimization features.

[onkoe]

Woah, thanks for the quick response! I appreciate the helpful link :)

It's not that I don't like musl and their libc, but it's just harder to work with. As someone who likes Rust a whole lot, it's a lot harder for me to build applications for riscv64gc-linux-unknown-musl due to its Tier 3 status.

Overall, despite a few benefits for embedded systems, musl is just a pain to work with. It feels like... old Linux 😱

Anyways, thanks for your help! I'll be following this issue closely.

[gtxzsxxk]

@onkoe

Hi, I mean the toolchain is not even a deal. Due to the open of risc-v, you can easily have your own version of the toolchain, by compiling the gcc or using buildroot. However, as I mentioned, If you are trying working with t-head's optimizations and features, you have to love musl.

If you don't care t-head's arch, you are just a risc-v user, please give up the t-head stuff, so that you can use the normal gcc and use glibc or any c lib you like. I highly suggest you have your own toolchain by using buildroot. Using the default configurations would have no t-head features and be compatible with the glibc and so on.

[onkoe]

I see - thank you! I'm somewhat unfamiliar with T-Head, as most of their top English-language search results are marketing and announcements.

By "give up" T-Head, do you mean to compile the buildroot kernel without some T-Head patches? If so, do you know if this is documented somewhere? I'm not quite well-versed enough to know what I'd need to remove.

Once again, thank you for your response! I'd love to see a glibc version come soon - I've spoken with other users who are having similar issues to me, though they're also in the Rust community. 😄

[gtxzsxxk]

Hello Barrett,

By "give up" T-Head, do you mean to compile the buildroot kernel without some T-Head patches? If so, do you know if this is documented somewhere? I'm not quite well-versed enough to know what I'd need to remove.

My "give up t-head" means that we use the toolchain with march rv64gc, rather than the rv64gcxthead, which is provided by the official sdk. During our work, the xthead stuff brought us a lot of trouble. But once removed, everything began to work.

./riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=./riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/root/embedded/host-tools/gcc/riscv64-linux-x86_64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/10.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/./source/riscv/riscv-gcc/configure --target=riscv64-unknown-linux-gnu --with-gmp=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/build-Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/lib-for-gcc-x86_64-linux --with-mpfr=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/build-Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/lib-for-gcc-x86_64-linux --with-mpc=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/build-Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/lib-for-gcc-x86_64-linux --with-libexpat-prefix=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/build-Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/lib-for-gcc-x86_64-linux --with-libmpfr-prefix=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/build-Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/lib-for-gcc-x86_64-linux --with-pkgversion='Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.6.1 B-20220906' CXXFLAGS='-g -O2 -DTHEAD_VERSION_NUMBER=2.6.1 ' --prefix=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1 --with-sysroot=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/build-gcc-riscv64-unknown-linux-gnu/Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.6.1/sysroot --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --enable-libsanitizer --disable-nls --disable-bootstrap --src=/mnt/ssd/jenkins_iotsw/slave/workspace/Toolchain/build-gnu-riscv_2/./source/riscv/riscv-gcc --enable-multilib --with-abi=lp64d --with-arch=rv64gcxthead 'CFLAGS_FOR_TARGET=-O2   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.6.1 B-20220906)

[onkoe]

Hey there! Have you progressed on this issue?