申请新增几大主流处理器架构的交叉编译工具链镜像

[lzufalcon]

为什么希望添加该镜像

交叉编译工具链 是学习处理器架构、汇编语言、Linux 内核、嵌入式 Linux、Linux 设备驱动开发等不可或缺的工具，目前这些工具基本由处理器研发厂商以及相应组织维护，都有提前编译好的版本，但是都托管在国外服务器上，体积都不小（几百M），国内下载很慢。

目前整理完的几大官方源如下：

ARM

https://releases.linaro.org/components/toolchain/binaries/

Linaro 是由 ARM 主导的技术联盟，该组织维护了大量 ARM 相关的开源软件，包括工具链，上述链接是提前编译好的 ARM 交叉编译器。

ARM 公司自己也提供了一些工具链：

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads

Risc-V

https://github.com/gnu-mcu-eclipse/riscv-none-gcc/releases

Risc-V 是当今最热门的处理器之一，相应的开发正热火朝天，所以，这些基础工具的同步非常关键。

注意：Sifive.com 提供的工具链无法编译最新的内核，因为没提供 -shared 支持，无法编译 vdso。上述工具链是目前找到的更新最快好用的 Risc-V 工具链。

MIPS

https://codescape.mips.com/components/toolchain/2018.09-03/downloads.html

MIPS 是四大主流处理器架构之一，上述 Toolchains 由 MIPS 官方发布。

增补两个全平台的：

全平台提供（For Linux）

https://toolchains.bootlin.com/

全平台提供（For Windows）

http://gnutoolchains.com/download/

---

欢迎大家回帖增补其他靠谱的 Toolchain 源

[zhsj]

和这些有啥区别呢？

https://packages.debian.org/source/buster/gcc-8-cross
https://packages.debian.org/source/buster/gcc-8-cross-mipsen
https://packages.debian.org/source/buster/gcc-8-cross-ports

[lzufalcon]

@zhsj 那个只是 Debian 下的，另外，我们申请的预先编译好，可以直接在 x86 平台的系统下载使用的。这个在实际工程中很有帮助，一般这种基础软件，不做这些软件本身的开发的话，是不需要源码的，先同步编译好的二进制包即可。源码的话，源比较多，使用也不是那么频繁，暂时不是那么迫切。

二进制包的发布和更新节奏比较慢，镜像工具复杂度应该没那么高。

另外，有企业希望对这部分工作提供赞助，具体怎么走流程呢？

[zhsj]

另外，有企业希望对这部分工作提供赞助，具体怎么走流程呢？

赞助请参考 https://lug.ustc.edu.cn/wiki/lug/finance/donate 但我无法确定对具体工作进行赞助是否有人接受。

[lzufalcon]

@zhsj 没关系的，对整个 ustc mirror 服务赞助也可以的，我们先了解一下，谢谢。

[comcat]

交叉编译工具链 (Toolchain) 是整个嵌入式软件工业的基础，应该逐步把现在国内常用体系结构的工具链都镜像了，加速产业进步。。。

[lzufalcon]

@comcat 是的，最好 TUNA 也可以加入进来，多一份镜像，多一份保障。

[lzufalcon]

@zhsj 您好，needvote 是点赞就 ok 吗？

[zhsj]

Debian包含大多数架构（包括MIPS、Arm、RISC-V，甚至Alpha）的交叉编译链。

[vowstar]

镜像工具链对于大陆本土意义非凡，强烈支持

[lzufalcon]

Debian包含大多数架构（包括MIPS、Arm、RISC-V，甚至Alpha）的交叉编译链。

是的，Debian 比较全，但是并不是所有同学都用 Debian 啊，用 Ubuntu 的占大多数，其他系统的也比较多，而且有些环境不一定有完整的系统环境，比如说在 Docker 里头使用。

[shankerwangmiao]

@zhsj 那个只是 Debian 下的，另外，我们申请的预先编译好，可以直接在 x86 平台的系统下载使用的。这个在实际工程中很有帮助，一般这种基础软件，不做这些软件本身的开发的话，是不需要源码的，先同步编译好的二进制包即可。源码的话，源比较多，使用也不是那么频繁，暂时不是那么迫切。

二进制包的发布和更新节奏比较慢，镜像工具复杂度应该没那么高。

另外，有企业希望对这部分工作提供赞助，具体怎么走流程呢？

问题是，Debian 提供的软件包也是编译好的，自然也可以很方便地安装和使用——甚至有了软件包的管理后，也能方便软件的更新和卸载等维护操作。我并不能看出来您所给出的二进制包有任何超乎于 Debian 提供的软件包的好处。

[lzufalcon]

考虑到部分同学在反复沟通后无法理解该需求，永久关闭该申请。

（更新个别措辞，对于所有人造成的困扰表示歉意。自己作为曾经的高校镜像站维护人员，理解维护的同学们在繁忙学业之余从事镜像站维护的难处，很感谢所有历史维护者和现在的维护者的付出。）

[lzufalcon]

请大家转到 tuna/issues#601

[taoky]

考虑到这边的同学无法理解该需求，永久关闭该申请。

很遗憾，@shankerwangmiao 并不是你所指的「这边的同学」。

你在 tuna 的 issues 讨论区域内也很有可能得到类似的消极回复。

[cuihaoleo]

考虑到这边的同学无法理解该需求，永久关闭该申请。

🌝 您楼上那个是 tuna 的网管。

[hosiet]

刚才我们这边做过了内部讨论，情况大概是
这样：

• @shankerwangmiao 是清华 tuna 那边的人士，不代表 ustclug 的意见；
• ustclug 内部有一部分人员现在不认为单独的（与发行版无关，或是 Windows 系统上）的工具链具有重要性，也有人认为这是（Linux）发行版应当承担的责任；
• 内部确认了除了上面的理解问题以外，主要障碍是技术问题：凡是上游没有提供同步和镜像支持的软件（例如上游提供 rsync 协议访问）我们只使用 http/https 进行镜像是存在文件一致性和及时性问题的，这属于技术困难。

综上，在问题解决之前应该是无法继续的。清华大学镜像站的意见可以在 tuna 的 GitHub issue 下另行讨论。

[lzufalcon]

@hosiet 谢谢组织内部讨论和总结。

就上面几点，我逐一回复一下：

• 第一点和第二点其实是同一个问题。其实无论从什么角度来看，和发行版无关的独立工具链是一个基础需求，这个其实不需要去讨论和证明的。在工业环境用各种发行版或者不用发行版是很常见的，假设大家都用 Debian 或者要求所有发行版都支持所有平台是没有意义的，比如 ArchLinux 天生只支持 X86，LFS 没有包管理，Buildroot 也没有，Ubuntu 不支持 MIPS，而 Risc-V 刚出来，绝大部分系统都不支持，不能因为这个需求，让大家都卸掉系统去装 Debian，这种讨论没有意义，是基本常识。

• 技术问题其实对于这个场景是有解的，首先这些工具链的更新不频繁，及时性其实对业界几乎没有影响，用 7.x 和 8.x 关系不是很大，两个版本的发行时间可能是论年的。另外，这种包都不多，只是个体稍微大一些，对某个源，并行下载可能一天内全部拉完了。关于一致性问题，在下载完，用 file 做后缀检查，用合适的压缩工具做一个解压验证其实应该都可以，实际使用中，用 wget -c 通常也没有碰到包损坏的问题。当然，你们可能在做大规模镜像的过程中之前有碰到更多复杂问题，可以再探讨。

我稍后会建立一个微信群，先拉 TUNA 那边的负责人进来，你们方便也可以加一下，我把企业那边的代表也喊一下。

[zhsj]

仅代表个人观点：

我稍后会建立一个微信群，先拉 TUNA 那边的负责人进来，你们方便也可以加一下，我把企业那边的代表也喊一下。

非常反对这种做法，请保持公开讨论。

[lzufalcon]

@zhsj 本来是希望组建一个直接沟通的渠道，促进高校和企业的沟通，如果反对，你可以不参加哈！

[shankerwangmiao]

您好，请注意您在公开场合的言辞。关于镜像站的运营事务，我们都是通过公开的 Github Issues 或者邮件列表沟通，这样既便于话题的跟踪，也使得其他关注者和用户能够提出自己的意见。其余不便公开讨论的问题，也可以通过发送邮件等方式进行交流。综上所述，沟通的渠道一直是畅通的，交流的大门一直是敞开的，您所谓的“直接沟通”的渠道无非是多此一举，画蛇添足。

@zhsj 本来是希望组建一个直接沟通的渠道，促进高校和企业的沟通，如果反对，你可以不参加哈！

[lzufalcon]

@shankerwangmiao 其实整个沟通过程中，我一直是很耐心的跟大家回复和解释需求的，但是各种无理由的反对已经是非常傲慢和无礼了，这个沟通中我看不到开源社区该有的基本的谦逊和友善！没有关系，大家认为没必要，就不要组织沟通了。由于大家的经历不一样，对一些背景信息的认知上有差异，导致对需求的理解不一样，而且这种纯文字的沟通效率本来就低下，才考虑组织直接的沟通。如果一上来不分青红皂白就摆出傲慢和反对的架势，沟通当然没有必要了，这是我参与社区十多年来经历过的最不愉快的一次活动。恕不再做任何回复！这笔申请完全撤销，也不再浪费大家精力！

[shankerwangmiao]

您好，我很愿意相信您是耐心地在进行回复，您所说的“无理由的反对”确实是存在的——由于镜像站的各方面资源具有稀缺性，对于每一个镜像请求，评估其必要性是维护团队的工作之一。如果您没能提供充分的支持材料，使得维护团队认可其必要性，那么自然这个镜像请求的必要性就要受到怀疑。就您的镜像请求而言，维护团队指出，您请求的内容与发行版自带的软件包出现了重复；然而您的回复却回避了该问题，而是讨论了工业环境中发行版的选择问题和发行版对不同架构（您原文是“平台”）的支持的必要性。事实上，从本人对相关行业的了解，我不认为工业环境的产品中会连带有编译器一起发布，因此最终产品所选取的发行版本与编译环境所选取的发行版本没有联系。从个人得知的部分消息来看，Debian 开发团队维护了质量相当高的交叉编译工具，安装和使用也非常方便——即使您不用 Debian 系统，也可以通过诸如直接从 deb 包中提取，或者通过 docker 容器等方法，从 Debian 团队的工作中受益。

您认为，“开源社区应该有基本的谦逊和友善”，对此我个人也表示赞同，开源社区的多数成员在对话过程中都会尽量保持克制。因此，我以及 USTC 的伙伴在表达的过程中，始终围绕着您的镜像请求的必要性向您询问，也向您解释了可能遇到的障碍。然而我看到的是，您并没有直接解答大家的疑惑，而是武断地认为“部分同学……无法理解该需求”，从而将“申请完全撤销”，并且在行文中反复使用感叹号等标点符号加强自己的语气。我很愿意相信您也有“基本的谦逊和友善”，但是我并没有体会到这一点。

您也提到，“大家的经历不一样，对一些背景信息的认知上有差异，导致对需求的理解不一样”，这是很正常而自然的情况，正因如此，我们才能保持社区内部的多样性，从而提高社区的生命力。这种生命力的提高，还需要保持密切的沟通，交换各自的想法和观点——如果只有多样性而没有沟通，绝不可能产生生命力。

您认为，“纯文字的沟通效率……低下”，因此需要通过“建立一个微信群”，来“组织直接的沟通”。我必须承认，人类大脑所处理的信息量和输出的带宽很是不匹配，因此用文字来表达的确有效率低下的问题。然而我并不能理解，微信群里可以进行什么样的超乎于纯文字的沟通，以至于可以比现在的沟通方式更加“直接”。现有的沟通方式是敞开的，并没有对任何人有任何的限制，我个人无法理解您的具体需求为何。

您提出，您的这次沟通，是“参与社区十多年来经历过的最不愉快的一次”，对此我个人表示遗憾。如果参与讨论的各方都能在沟通中保持“基本的谦逊和友善”，我相信您的体验可能会好很多。