LA UOSC

其实我不明白为什么不学习arm，使用LArch这种名称呢

lingfengzhe 看完整个帖子，你就会发现，有些东西xen0n已经说得很清楚了。有些东西就是中英文习惯的问题。就像表头是架构名（类型），里面其他是ARM，X86，MIPS，Loong，这样就感觉很正常。你叫Loongarch就显得冗长 。所以我个人的建议，能完整用的时候就Loongarch，需要缩写的时候就Loong。

PS：感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

lingfengzhe 其实我不明白为什么不学习arm，使用LArch这种名称呢

曾经就是 larch，有的地方现在还是：例如工具链里的重定位类型。（没错，龙芯中科自己就搞不一致，一边 loongarch 一边又 LARCH。之前跟他们提过要不要改 LOONGARCH 或者 LOONG 被明确拒绝了，而且没实质理由。说法大致是“工具链项目统一使用 larch”但没有给出其他原因。）

至于曾经使用过 larch 的证据，在极早期的一些龙芯工具链 fork 项目中可以窥见端倪：例如龙芯的 Go 1.15.6 fork，第一个 fork 提交使用的名字就是 GOARCH=larch64。

后边直到提交上游前夕，才批量替换成 loongarch64。再后来的事情大家也都知道了，他们批量替换了第三次。。

按说，龙芯注册了 LArch 的商标，应该用起来，或者至少早些时候就开始宣传以此作为 LoongArch 的简称才对。结果他们并没有。。LArch 也基本被世人遗忘。现在已经没有机会回去了，较短名称已经到处都在用 loong 了。从推广中国龙文化（Loong != Dragon）的角度，倒也是一件好事。。

REDEAST 感觉大家对完整写法没有意见，现在成了讨论缩写规范了。

这个也是没办法的事情，他们工具链上提前占位了 loongarch64-unknown-linux-gnu 了，unknown 的部分大家都一样（历史原因），后边大家也一样，就是前面太 tm 长了。可能是搞 mips64el 多了不觉得 loongarch64 长了，毕竟 MIPS R6 更长：mipsisa64r6el 表示 MIPS64r6 小端。除此之外，差不多长的架构也就 microblaze 这种了，LA 绝对是可预见的未来“常见”架构里名字最长的了。

既然 GNU target tuple 事实上已经定下来了，那为了一致，只好尽量在别的地方厚着脸皮往里推了。当时在 review systemd 代码的时候，纠结半天，还是用 ARCHITECTURE_LOONGARCH64，很难绷住，最后整个文件一大片定义都重新做了遍垂直对齐。。

https://github.com/loongarch64/systemd/pull/5

https://github.com/systemd/systemd/pull/21288/files

Larch 替换了三次说明他们在做之前都没想好，或者公司宣传口的变化，或者没有意识到这是个问题。

至于对齐，其实不算个事，这个对齐都是长的加进来慢慢变的。

大道无形若水 龙芯64位架构

lx64类比 sw64

时空质能 下划线发不出来

5.LoongArch Slackware current bootstrap项目源码地址：https://github.com/shipujin/slackware-loongarch64

6.发布v0.1:LoongArch-slackware64-current-bootstrap-20220708：详细信息请看 Release v0.1

LoongArch slackware64 current 运行信息

LoongArch slackware64 current系统使用的核心基础软件三件套(除glibc使用的是github下的loongson/glibc)，像gcc、binutils、linux-headers都是使用上有社区release版本，具体软件版本可查阅项目的Release/v0.1

最近我在玩LoongArch Slackware，都想仰天长啸，太爽了

因为Slackwae是一个编译打包（编译过程中缺失会正常输出缺失的东西）、安装、移除软件不提示依赖关系的

所以在构建LoongArch Slackware64 current bootstrap时，我想编译啥编译啥，完全不像移植其他distro时被发行版自身识别的依赖搞得烦躁，

构建LoongArch Slackware完全随身所欲(个人需谨慎(狗头，自我发挥性高，让我有种回到了LFS时期，但又有简单的包管理器去控制系统，真的太爽啦！！！

大道无形若水 软件依赖问题怎么解决？还有大佬，你的自动交叉编译工具能放出来吗？学习学习

时空质能 依赖问题怎么解决？还有大佬，你的自动交叉编译工具能放出来吗？学习学

1. 软件依赖问题，就是基础工具软件编译一般都已烂熟于心、其他库软件，按编译时提示进行编译，不用死记硬背，做多了就熟悉了

2. 自动化工具方面，我都是做哪个发行版现写，其实也都算不上自动化，具体可以参考lfs、alfs，

   ( 需要的参考的话，后面我把之前fork的archlinux的自动化工具，适配为loongarch64的自动化工具分享出来

我感觉简写成la64不错

狗剩 如果说写简写，感觉不如LARCH64

LoongArch Slackware current 最新进展：

lingfengzhe

W̶h̶y̶ ̶n̶o̶t̶ ̶c̶a̶l̶l̶ ̶i̶t̶ ̶T̶C̶O̶A̶ ̶(̶t̶h̶e̶ ̶c̶h̶i̶n̶a̶ ̶o̶w̶n̶s̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶)̶ ̶ ̶o̶r̶ ̶T̶C̶A̶ ̶(̶t̶h̶e̶ ̶c̶h̶i̶n̶e̶s̶e̶ ̶a̶r̶c̶h̶i̶t̶e̶c̶t̶u̶r̶e̶)̶ ̶?̶

LoongArch Slackware current最新进展：图形桌面已出来，后续还需要重新滚动一遍图形相关的软件，下面是运行展示

8. 发布v0.3:slackware-current-bootstrap-2022.10.12-loong64

• 重新构建工具链，使用构建好的new reloc v2.0 ABI工具链进行系统构建
• 新世界系统，ELF 文件带 OBJ-v1 标志，以区分旧世界

0 root:~ # readelf -h /bin/bash | grep Flags
  Flags:    0x43, DOUBLE-FLOAT, OBJ-v1

• Slackware 系统仓库搭建，进行中...

9.发布slackware mini install 镜像：slackware64-current-loong64-20221122-mini-install.iso

root@slackware:/# uname -a
Linux Slackware 6.1.0-rc5 #5 SMP PREEMPT Sat Nov 19 10:58:45 UTC 2022 loongarch64 GNU/Linux

制作U盘启动盘方法并启动：

• 下载slackware64-current-loong64-20221122-mini-install.iso

• 命令行执行：

    dd if=slackware64-current-loong64-20221122-mini-install.iso of=/dev/设备号 bs=1M

• 插上刻录好的U盘，对LoongArch 机器调整UEFI，设置为U盘启动

• 开机，即可进入 slackware64 current mini install系统中

10.完成slackware 20230213010936(上游tag状态)构建