Hi @FreeFlyingSheep . I found the qemu tool address has been changed. And the address in readme does not have .bin extension.
https://github.com/loongson/build-tools/blame/750aa562ae8a2a943c06829322bc5862c89ee11e/README.md#L23

Old url : https://github.com/loongson/build-tools/releases/download/2022.09.06/qemu-loongarch64
New url: https://github.com/loongson/build-tools/releases/download/2022.09.06/qemu-loongarch64.bin

This change break my ci action. Can you keep the file address unchanged? Thanks a lot.

github.com/loongson/gcc 的loongarch-12分支
编译 poppler时，会出错

 g++ poppler_Decrypt_preprocessed.cc -c
/var/tmp/portage/app-text/poppler-21.12.0/work/poppler-21.12.0/poppler/Decrypt.cc:1826:1: 编译器内部错误：在 output_constructor_regular_field 中，于 varasm.c:5512
 1826 | }
      | ^
0x1134277 internal_error(char const*, ...)
        ???:0
0x1a2887 fancy_abort(char const*, int, char const*)
        ???:0
0xbdecbf assemble_variable(tree_node*, int, int, int)
        ???:0
0xbe24ab varpool_node::assemble_decl()
        ???:0
0x4c2067 symbol_table::finalize_compilation_unit()
        ???:0
请提交一份完整的错误报告，
如有可能请附上经预处理后的源文件。
Please include the complete backtrace with any bug report.
参阅 <https://bugs.gentoo.org/> 以获取指示。

使用clfs原生工具链，也类似

/opt/clfs/usr/bin/g++ poppler_Decrypt_preprocessed.cc -c 
/var/tmp/portage/app-text/poppler-21.12.0/work/poppler-21.12.0/poppler/Decrypt.cc:1826:1: internal compiler error: in output_constructor_regular_field, at varasm.c:5512
 1826 | }
      | ^
0x12110ad07 internal_error(char const*, ...)
        ???:0
0x1201b4aff fancy_abort(char const*, int, char const*)
        ???:0
0x120bccb07 assemble_variable(tree_node*, int, int, int)
        ???:0
0x120bd0223 varpool_node::assemble_decl()
        ???:0
0x1204d4b23 symbol_table::finalize_compilation_unit()
        ???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

使用clfs cross工具链，则无问题

llvm 则基本一致
使用loongarch工具链有问题，clfs la原生工具链有问题
使用gcc 11 x86编译无问题，clfs cross工具链无问题
使用loongarch源码编译的 x86_64 g++则有同样问题

gcc bugzilla有类似报告，不过看起来不像是同一个问题
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102434

目前 README 中下载地址链接到了其他用户名下的仓库（目测是贵司的员工），但考虑到已经有 loongson 组织的官方仓库，建议将相关仓库挪到 loongson 组织下，这样比较正式，否则在外人看来，就会觉得贵司的开发和权限管理出现了割裂。

主机需要常时跑windows干活，目前靠wsl和虚拟机提供linux环境，主机性能有限不足以在虚拟机中跑qemu，wsl还没试过，估计也够呛（而且不是标准linux内核），希望能编译一个windows nt x64环境下原生运行的环境用来测试

你好，我刚开始接触龙芯编译工具链，在使用loongarch64-linux-gnu-2021-06-19.tar.gz的时候遇到一些问题：
1、使用loongarch64-linux-gnu-gcc编译一个简单的c代码，发现编译出来的目标文件架构不对 ，是因为需要指定架构吗？

另外，可以提供关于这个工具链的使用文档吗？
谢谢！

能否为v语言添加适配
https://github.com/vlang/v

请问有可以公开的 LLVM 源码吗？今天看新闻说龙芯的工程师已经用 clang 编译虚幻引擎了。

主要是 rustc 需要 LLVM，如果 LLVM 弄好的话 rustc 我看了一下应该写几百行 (?) 代码描述一些机器特性就行。

如果没有的话我可能去试着玩玩 gccrs 或者 rustc 的 libgccjit backend……

Some toolchain tarballs from the Releases Download section have incorrect file extensions.

They claim to be .tar.xz files, but in fact these were compressed with gzip instead and should carry the .tar.gz extension.

For example https://github.com/loongson/build-tools/releases/download/2022.09.06/loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz:

Extracting it as xz files does not work:

$ tar xJf ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                               
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Here we see that this is in fact a gzip file:

$ file ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                                  
./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz: gzip compressed data, from Unix, original size modulo 2^32 3332720640

Extracting with the options for gzip works:

$ tar xzvf ./loongarch64-clfs-6.3-cross-tools-gcc-full.tar.xz                                            
cross-tools/
cross-tools/share/
cross-tools/share/locale/
cross-tools/share/locale/da/
cross-tools/share/locale/da/LC_MESSAGES/
[...]

首先感谢龙芯社区开发者的积极付出，让LoongArch这一新平台也有了属于自己的GCC，为开源社区的持续发展打下了坚实基础。

考虑到GCC是基于GPL的自由软件，原则上需要公布修改后的源代码；并且为新架构提供支持，本身就是值得反馈给GNU上游的巨大贡献（龙芯MIPS架构支持已经是GNU官方源码的一部分）。

因此建议龙芯社区团队在此发布源代码，而不仅仅是二进制版本。这样能让更多开发者作出贡献，开启更多新可能。

参考https://github.com/foxsen/edk2-platforms/blob/devel-LoongArch/Platform/Loongson/LoongArchQemuPkg/Readme.md的步骤，遇到这个错误
loongarch64-linux-gnu-gcc: error: unrecognized command line option '-mno-explicit-relocs'; did you mean '-fno-implicit-none'?
当前gcc是这个版本
sing built-in specs.
COLLECT_GCC=loongarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/loongson-gnu-toolchain-8.3-x86_64-loongarch64-linux-gnu-rc1.1/bin/../libexec/gcc/loongarch64-linux-gnu/8.3.0/lto-wrapper
Target: loongarch64-linux-gnu
Configured with: /dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/src/gcc/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=loongarch64-linux-gnu --program-prefix=loongarch64-linux-gnu- --prefix=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross --libdir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/lib --with-gxx-include-dir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot/usr/include/c++ --with-sysroot=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot --with-native-system-header-dir=/usr/include --with-slibdir=/dev/shm/build_loongarch64_gcc8-host-x86_64-rc1.1_2022-09-14/cross/sysroot/usr/lib --with-pkgversion='LoongArch GNU toolchain rc1.1 (20220914)' --with-arch=loongarch64 --with-abi=lp64d --with-multilib-list=lp64d,lp64s --enable-checking=release --disable-linker-build-id --enable-languages=c,c++,fortran --disable-libgcc --disable-libstdc++ --disable-libgfortran --disable-gcov --enable-libcc1 --enable-threads=posix --enable-tls --enable-initfini-array --enable-__cxa_atexit --disable-libatomic --disable-libmudflap --disable-libvtv --disable-libgomp --disable-libmpx --disable-nls --disable-bootstrap
Thread model: posix
gcc version 8.3.0 (LoongArch GNU toolchain rc1.1 (20220914))
请问是否当前gcc不支持该命令参数？

我使用 loongarch64-clfs-20210812-cross-tools ，想要生成 32bit 的目标代码。

试过
loongarch64-unknown-linux-gnu-gcc -march=loongarch32 a.c
loongarch64-unknown-linux-gnu-gcc: error: unrecognized argument in option ‘-march=loongarch32’

提示
version GLIBC_2.38' not found version GLIBC_2.36' not found
ld-linux-loongarch-lp64d.so.1 => not found
系统是麒麟v10

Hi

我想用qemu搭一个loongnix的最小系统，以便chroot进去编译我的程序，避免交叉编译的一些麻烦。

步骤：

1. debootstrap --no-check-gpg --variant=minbase --components=main,non-free,contrib --arch=loongarch64 --foreign DaoXiangHu-stable rootfs-loongarch64 http://pkg.loongnix.cn/loongnix/
2. 使用https://github.com/loongson/build-tools/releases/download/2022.05.29/qemu-loongarch64 这版，然后配置好binfmt
3. sudo chroot rootfs-loongarch64 /debootstrap/debootstrap --second-stage

此时报错/bin/sh: error while loading shared libraries: libc.so.6: cannot stat shared object: Error 38

测试环境为Ubuntu 20.04 amd64

有看到这个issue：#18 ，但他最后的解法是换工具链，而我是想用loongnix的官方源。

感谢！

kernel 载入后键盘灯闪一下卡死
拿掉 acpi_initrd 也起不来
启动参数带 verbose ignore_loglevel 也没提示
接上串口 consoleblank=0 earlyprintk=ttyS0 console=ttyS0 nomodeset 串口也没信息

主板：LM-LS3A5000-7A1000-1w-V01-pc_A2101
固件:
Vendor: ZD-TECH
Version: KL.4.1H.LM.D.025.211109.R
Release Date: 11/09/2021
ROM Size: 8192 kB

Using either prebuild toolchain , or custom build toolchain from loongson repo(gcc-12 binutils-2.37 glibc-2.33)

/tmp/cc3MOy9W.s:537: Fatal error: no match insn: li $r12,0x4
{standard input}:887: Fatal error: no match insn: stl.w $r4,$r24,3

grub2
source https://github.com/loongarch64/grub/tree/dev-la64

In file included from ../../include/grub/relocator.h:25,
                 from ../../include/grub/loongarch64/relocator.h:24,
                 from ../../grub-core/lib/loongarch64/relocator.c:27:
../include/grub/cpu/memory.h: In function ‘grub_map_memory’:
../include/grub/cpu/memory.h:39:50: warning: unused parameter ‘size’ [-Wunused-parameter]
   39 | grub_map_memory (grub_phys_addr_t a, grub_size_t size)
      |                                      ~~~~~~~~~~~~^~~~
/tmp/cc3MOy9W.s: Assembler messages:
/tmp/cc3MOy9W.s:537: Fatal error: no match insn: li     $r12,0x4
Makefile:41604: recipe for target 'lib/loongarch64/relocator_module-relocator.o' failed

kernel
source https://github.com/loongson/linux/tree/loongarch-next

:~/mylaos/build/linux-5.13.0$ ARCH=loongarch CROSS_COMPILE=/home/lin/work/loongarch64-linux-gnu-2021-08-03/loongarch64-linux-gnu/bin/loongarch64-linux-gnu- make    
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  CHK     include/generated/compile.h
  CC      arch/loongarch/kernel/unaligned.o
{standard input}: Assembler messages:
{standard input}:887: Fatal error: no match insn: stl.w $r4,$r24,3
scripts/Makefile.build:272: recipe for target 'arch/loongarch/kernel/unaligned.o' failed
make[2]: *** [arch/loongarch/kernel/unaligned.o] Error 1
scripts/Makefile.build:515: recipe for target 'arch/loongarch/kernel' failed
make[1]: *** [arch/loongarch/kernel] Error 2
Makefile:1847: recipe for target 'arch/loongarch' failed
make: *** [arch/loongarch] Error 2

Dear Loongson Community:

We are migrating python conda to loongarch64 (and maybe mips64), c.f. conda

Now an issue emerges, when porting conda-build, a Centos 7 repository seems to be required, like the code sample sections one for CPU arch IBM S390X:

S390X support

          'clefos': {'dirname': 'clefos',
                     'short_name': 'cos7',
                     'base_url': 'http://download.sinenomine.net/clefos/7/os/{base_architecture}/',  # noqa
                     'sbase_url': 'http://download.sinenomine.net/clefos/7/source/srpms/', # noqa
                     'repomd_url': 'http://download.sinenomine.net/clefos/7/os/repodata/repomd.xml', # noqa
                     'host_machine': '{gnu_architecture}-conda-cos7-linux-gnu',
                     'host_subdir': 'linux-s390x',
                     'fname_architecture': '{architecture}',
                     'rpm_filename_platform': 'el7.{architecture}',
                     'checksummer': hashlib.sha256,
                     'checksummer_name': "sha256",
                     'macros': {'pyver': '2.7.5',
                                'gdk_pixbuf_base_version': '2.36.2'}},

a loongarch64 version repository may be required to work with conda build. Now wondering, does anyone knows a working centos repository, or the CLFS tools here build-tool could be used to build one.

Many thanks,

龙芯开发着您好。我观察到qemu在7.1.0已经支持龙芯架构了，但是目前并没有有关如何使用qemu-system-loongarch64启动操作系统的教程，请问官方可以提供一个教程吗？

GNU Toolchain Combination Status of the LoongArch

Preamble

This is a document used to test whether different versions of Binutils, GCC, and Glibc in LoongArch can be built and used normally.

We selected the latest release of each major version for testing.
These sources are obtained from https://ftp.gnu.org/gnu.

• Binutils tested 5 release versions: 2.38, 2.39, 2.40, 2.41, 2.42, and 1 development version 2.43.
• GCC tested 3 release versions: 12.3.0, 13.2.0, 14.1.0, and 1 development version 15.
• Glibc tested 4 release versions: 2.36, 2.37, 2.38, 2.39, and 1 development version 2.40.

Table of Contents

• GNU Toolchain Combination Status of the LoongArch
  • Preamble
  • Upstream Toolchain Combination Testing
    • 1. Test Process
    • 2. Test Results
  • Toolchain Support of ABI Instructions and new Features
    • LoongArch ABI Revision History
    • Binutils Relate Support
      • Binutils New Features Description
    • GCC Relate Support
      • GCC New Features Description
    • Glibc Relate Support
      • Glibc New Features Description
  • Problematic situations

Upstream Toolchain Combination Testing

The test of build process is based on cross-compilation: first, build the toolchain by cross-compiling; second, use this toolchain to compile and run the spec 2006 and 2017.

1. Test Process

• Compile and install a versions of Binutils.
• Use the new Binutils to build a degraded GCC that does not depend on the host Glibc. If this version of Binutils cannot build GCC, it is considered that the two cannot be combination.
• Install the linux-6.8.4 kernel.
• Compile a version of Glibc using the new GCC and Binutils.
• Compile a complete GCC with new Binutils and Glibc.
• Compile and run the spec 2006 and 2017 test using the toolchain above. The test uses -march=loongarch64 -Ofast and does not use vector instructions.
• If any of the above test steps fails, it is considered that the corresponding version of the toolchain cannot be combination.

Note:

• GCC requires the GMP, MPFR and MPC packages. As these packages may not be included in host, run the contrib/download_prerequisites script in the GCC source directory to obtain these packages,they will be built with GCC.
  If the versions of config.guess and config.sub in the source of these packages are too low, copy them from the gcc source directory.

• GCC configure uses the default march and abi.

2. Test Results

The combinations that can complete all test processes are shown in Table 1.

The columns in the table are Binutils versions, the rows are GCC versions, and the intersection between them is the Glibc version. The X of intersection between them means that a certain step in the test process cannot be completed, which we call uncombinable.

Table 1. result of toolchain combinations

Note:

• Binutils 2.38 cannot build any version of degraded GCC.
  Binutils 2.38 uses two ABI names, lp64 and ilp32, and GCC uses 3 ABI names, lp64d, lp64f, and lp64s. The default lp64d option passed by GCC is not recognized by the 2.38 version of the assembler.

• Binutils 2.39 and 2.40 cannot build degraded GCC 14 and 15.
  GCC 14 and 15 use la64v1.0 as the default march, which enables lsx to generate vector instructions and causes Binutils 2.39 and Binutils 2.40 to be unrecognized.

• Glibc 2.39 requires Binutils vector instruction support, and Binutils 2.41 and above add vector instruction support.

Toolchain Support of ABI Instructions and new Features

LoongArch ABI Revision History

For more information about ABI, please see the following link. Only some of the changes between versions are listed here.
https://github.com/loongson/la-abi-specs.

• v1.00
  • Add register usage convention, data type conventions and the list of ELF relocation types.
• v2.00
  • Add description of ILP32 data model.
  • Add description of return value register aliases.
  • Add relocation types with direct immediate-filling semantics.
• v2.01
  • Adjust description of ABI type encoding scheme.
• v2.10
  • Add the DWARF standard for the LoongArch architecture (ladwarf) document.
  • Differentiate machine data types with the C/C++ types.
• v2.20
  • Revise the parameter passing rules of structures.
  • Add R_LARCH_CALL36 relocation type.
  • Remove R_LARCH_DELETE and mark its relocation number as reserved.
  • Remove R_LARCH_CFA and mark its relocation number as reserved.
• v2.30
  • Add vector arguments passing rules to the base ABI.
  • Add relocation types for TLS Descriptors.

Binutils Relate Support

Table 2. ABI, instruction set, and new feature support for Binutils

Binutils New Features Description

Descriptions of new features are available along with the Binutils release at the following link. Only some of the changes are listed below.

binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_42-branch.
gas: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/heads/binutils-2_42-branch.
ld: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/heads/binutils-2_42-branch.

• Link relaxation:
  A link-time optimization that reduces the number of instructions required to access a symbol.
  Set gcc/as -mrelax/-mno-relax to enable/disable link relaxation.
  Set ld --relax/--no-relax to enable/disable link relaxation.

• TLS Descriptors:
  It is a more efficient alternative to the traditional general dynamic and local dynamic TLS models.
  Configured GCC with --with-tls=desc to enable TLS Descriptors by default.
  Set GCC -mtls-dialect=desc to enable TLS Descriptors.

• TLS type transition
  Transition to a more efficient TLS access model.
  There are currently 3 transitions implemented:

  • desc -> ie
  • desc -> le
  • ie -> le

GCC Relate Support

Table 3. Instruction set, and new feature support for GCC

GCC New Features Description

Descriptions of new features are available along with the GCC release at the following link. Only some of the changes are listed below.
https://gcc.gnu.org.

• Code model:

  • medium code model:
    The text segment and data segment must be within 2GB addressing space.
    Set gcc option -mcmodel=medium to use medium code model.

  • extrme code model:
    This mode does not limit the size of the code segment and data segment. The -mcmodel=extreme option is incompatible with -fplt and/or -mexplicit-relocs=none.
    Set gcc option -mcmodel=extreme to use extreme code model, incompatible with -mno-explicit-relocs.

• Subprojects Support:

  • libvtv support.

  • libitm support.

  • Address sanitizers other than HWASan and TSan are now supported on LoongArch.

• Add more -march parameters:

  • la64v1.0
  • la64v1.1
  • la664

• Add more -mtune parameters:

  • generic
  • la664

• TLS Descriptors:
  Compiler support for TLS Descriptors.
  The current default configuration is --with-tls=trad. Configured GCC with --with-tls=desc to enable TLS Descriptors.
  Set GCC -mtls-dialect=desc to enable TLS Descriptors. Set GCC -mtls-dialect=trad to enable Traditional TLS model.

Glibc Relate Support

Table 4. New feature support for Glibc

Glibc New Features Description

Descriptions of new features are available along with the Glibc release at the following link. Only some of the changes are listed below.
https://sourceware.org/glibc.

• setjmp/longjmp pointer encryption
  During the setjmp/longjmp process, the ra/sp pointers are encrypted and protected by random numbers.

• Atomic operation
  Supports atomic operation instructions.

• Floating point function builtin
  Implemented builtin support for floating-point functions.

• Soft-float ABI
  Supports soft floating point ABI.

• LoongArch static PIE
  Supports static PIE executable programs.

• _dl_runtime_resolve vector implementation
  Added lsx 128-bit implementation _dl_runtime_resolve_lsx and lasx 256-bit implementation _dl_runtime_resolve_lasx.

• _dl_runtime_profile function
  Add dynamic linker _dl_runtime_profile function.

• str/mem function vector implementation and ifunc
  Add multiple versions of str/mem functions and implement ifunc functionality.

• Improve ldconfig function
  Add and improve the functions of ldconfig.

• Tunables
  Add glibc.cpu.hwcap support for tuning HWCAP feature.

• TLS Descriptors
  Glibc support for TLS Descriptors.

Problematic situations

• The default configure for GCC12 and 13 is --with-arch=loongarch64, and for GCC 14 and above is --with-arch=la64v1.0.
  If you want to use GCC 14 and above with Binutils2.39 and 2.40, you need to configure GCC as --with-arch=loongarch64.

• To generate vector instructions using -mlsx/-mlasx, only GCC 14 can be used, and Binutils 2.41 and above can be used.

• If -falign-labels is used but not falign-labels=0/1/2/3/4, GCC 12 13 cannot be used with Binutils 2.42. This is because of a change in the behavior of Binutils in handling .align.
  GCC14 and above with Binutils2.42 are not subject to the above restrictions.

在最新的内核代码中，struct sigcontext 的对齐由 32 降为了 16：https://github.com/loongson/linux/blob/loongarch-next/arch/loongarch/include/uapi/asm/sigcontext.h#L24

内核里面的 struct ucontext 最后一个字段是 struct sigcontext，但是 glibc 里面的 struct ucontext 最后一个字段是 mcontext_t，后者仍然是 32 字节对齐。这导致内核与 glibc 的 struct ucontext 布局不一样，而 libgcc 里面又有一个

      struct rt_sigframe
      {   
        siginfo_t info;
        ucontext_t uc;
      } *rt_ = context->cfa;

这里 ucontext_t 是 glibc 的 struct ucontext，结果 rt_sigframe 的结构和内核不一样了。然后用到 libgcc unwinder 的程序会在这里挂掉。

因为内核那边没开 Issues，报到这里了。

最近有一个法院的项目需要rust语言在x86 Ubuntu系统上跨平台交叉编译应用程序到Loongson-3A4000的笔记本电脑上。问一下编译loongarch64-unknown-linux-gnu能否在Loongson-3A4000上跑？
lscpu:
Architecture: mips64
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Model name: Loongson-3A R4 (Loongson-3A4000)

尝试在qemu7.1(win32/amd64)启动最新clfs镜像：

qemu-systrm-loongarch64.exe -m 1024 -smp 2 --cpu la464 --machine virt -bios QEMU_EFI.fd -drive file=loongarch64-clfs-system-6.3.qcow2,if=virtio -vga virtio

loongarch64-clfs-system-6.3.qcow2使用release中rootfs制作，QEMU_EFI.fd来自yangxiaojuan-loongson/qemu-binary
去掉grub中quiet选项启动，在较长时间后出现ramdom: crng init done并卡住

该压缩文件的格式是gzip而非xz，请更正压缩包的后缀，对使用者产生了严重误导导致无法正确解压缩。此外解压缩之后的文件夹名建议依然是loongarch64-clfs-6.3-cross-tools-gcc-full，目前是cross-tool，解压缩之后不容易找到。

据我所知，loongarch架构的Rust编译工具链已经出来了，请问在哪里能找到呢？

上个版本有发布的qemu，怎么这次删掉了？
需要这个qemu在x86服务器上跑ci

so I tried several ways to hint the compiler to utilize SIMD extension, but the codegen is very funny:


given that the instruction manual for the SIMD extension is still not open for us, I would like to ask will such extensions be made public for all developers finally?

我们使用 loongarch64-clfs-2022-03-03-cross-tools-gcc_and_clang-full.tar.xz 工具链，在 Debian Linux x86_64 上编译以下源代码：

#include <stdio.h>
int main(void) {
        printf("Hello LoongArch!\n");
        return 0;
}

使用的编译指令为：

clang --target=loongarch64-unknown-linux-gnu hw.c -o hw

由于 Debian 上没有安装过 LLVM，所以可以确定使用的就是工具链的 clang。

将编译生成的二进制文件上传到 Loongnix-Server Linux 8 loongarch64 的机器上无法运行，提示：

-bash: ./hw: No such file or directory

再使用

clang --target=loongarch64-unknown-linux-gnu hw.c -static -o hw

在同样的龙芯机器上可以正常运行，故怀疑动态链接存在问题？

孙老师您好，CLFS20210903版本里面最开始的下载链接中关于Perl的下载后面多了个z
原文：Perl: https://www.cpan.org/src/5.0/perl-5.34.0.tar.gzz
应该修改成：Perl: https://www.cpan.org/src/5.0/perl-5.34.0.tar.gz