CentOS 7的Glibc只有2.17

[landall]

运行时需要高达2.28的依赖是必要的么？

[PeratX]

可以选用musl编译的二进制文件 依赖glibc是由github actions客户机决定的 https://github.com/iTXTech/mcl-installer/releases/download/f7ee211/mcl-installer-f7ee211-linux-amd64-musl

[landall]

目前github actions没法选择centos？我看.action配置里只有ubuntu系的配置。 这个系列的编译环境，相对于redhat系的基础库，版本一般要高特别多。

我是直接下载mcl，好像只需要yum一个epel库的latest版本的java（目前是17）就能运行了。

[landall]

看了眼github actions的帮助，没有centos，默哀……

[PeratX]

github官方只提供ubuntu，所以可以选用musl libc编译的二进制文件，没有任何外部依赖。

[PeratX]

目前github actions没法选择centos？我看.action配置里只有ubuntu系的配置。 这个系列的编译环境，相对于redhat系的基础库，版本一般要高特别多。

我是直接下载mcl，好像只需要yum一个epel库的latest版本的java（目前是17）就能运行了。

这个当然是可行的，如果条件允许的话，最好是通过系统提供的包管理系统来安装openjdk，目前mcl和mirai支持java11及以上jdk运行

[landall]

我简单读了下installer做的事情，我感觉其中大部分工作，通过deb和rpm就能实现，其实打包成系统软件的包，会更利于管理的。 Windows下好像确实缺少比较容易用的包管理器。

[PeratX]

java的jar和其他软件包一般不会通过包管理器直接shipping

[PeratX]

installer主要还是侧重于在各类系统上安装java运行时，包括linux macos 和windows，且支持多种cpu体系结构，并没有外部依赖（linux可选用musl）

[landall]

这个其实还是个喜好的风格问题。在安装java运行时这个问题上，我觉得脱离系统包管理去做，其实是有一些重复造轮子的。 包括mcl本身我也倾向于它应该遵守系统的包管理（包括windows下其实应用商店是最规范的选项）的。 能避免许多的重复工作。这些包管理工具都有比较完整的cpu体系的管理能力。

反而是插件这些，应该用类似于npm和php composer的方法去做发布管理。

[comradez]

最新版本 Release 中 Linux AMD64 架构没有 musl 编译的二进制文件 我的服务器也没用 2.28 / 2.29 版本的 glibc，所以只好自己装一个 nightly toolchain 然后 build from src，做完之后想来提 Issue 才发现原来这里还藏着一个 musl 编译的二进制。

我的想法是，rust 这种比较依赖 glibc 的语言，可能并不适合分发单一的预编译二进制文件——除非你针对常见发行版常见版本各自提供 binary。但是在服务器上编译 rust 又是一件很麻烦的事情，像是在给用户徒增负担。

[PeratX]

最新版本 Release 中 Linux AMD64 架构没有 musl 编译的二进制文件 我的服务器也没用 2.28 / 2.29 版本的 glibc，所以只好自己装一个 nightly toolchain 然后 build from src，做完之后想来提 Issue 才发现原来这里还藏着一个 musl 编译的二进制。

我的想法是，rust 这种比较依赖 glibc 的语言，可能并不适合分发单一的预编译二进制文件——除非你针对常见发行版常见版本各自提供 binary。但是在服务器上编译 rust 又是一件很麻烦的事情，像是在给用户徒增负担。

那我发布一个带musl的新版本把，目前还是prerelease状态