WÁNG Xuěruì
WÁNG Xuěruì
Finally, please add `Signed-off-by` line. (see that failing DCO check?) While at it, modify your PR title and commit message so LoongArch64 is uniformly referred to as `loong64` in the...
目前这种锚定依赖版本的做法，实质上排除了客户在（阿里数据库服务器不采用的）新兴架构上自愿运行 OceanBase 的可能性。一些国内外近年才出现的新兴架构，如 RISC-V 或 LoongArch，并不被锚定的老旧依赖版本所支持，但实际上作为技术的上游提供者，相信你们也并不希望这些人被排除在目标用户群体之外。 一种解决方法是引入**分层支持** (tiered support) 的概念。以 [Rust 语言的平台支持策略](https://doc.rust-lang.org/rustc/platform-support.html)为参考，可以考虑以下的划分： * Tier-1：将获得完整的 CI 覆盖、测试覆盖、技术支持；包括目前你们所“官方支持”的所有架构、操作系统组合。 * Tier-2：代码有支持，CI 依赖相应维护者但不保证，没有技术支持；包括 RISC-V、LoongArch 等架构。 * Tier-3：所有其他场景，对功能不作任何保证（No Warranty）。 EDIT: 本人与 RISC-V 或 LoongArch 利益不相关，但...
感谢及时回复！ > 我们的用户有几百家金融用户, 而且我们是一个oltp的数据库, 承载着无数金融核心系统的稳定和安全, 我们不期望因为一些其他的缘故, 而导致莫名其妙的错误. > > 另外一个事实, 就是我所知道的商业数据库, 都是一个稳定的工具链, 不是让数据库在任何环境下都能随意的编译. 另外, 我们曾经发生过因为升级工具链而发生过故障, 所以这个事情, 我们是有教训的. 理解这个需求，不过可能这场景和新兴架构支持并不冲突——从商务、技术、法律视角看，只要明确界定何种配置（例如，必须采用官方发布的二进制，必须满足一定的系统基础组件版本范围之类）才适用稳定性、安全性的承诺，那么其他人自己折腾应该是自愿、自由的，这也和开源精神一致。 > 工具链, 我们内部有专门的编译团队来评估工具链, 如果现在RISC-V 或 LoongArch 不能提供我们相应的版本, 麻烦你们说一下你们能提供什么版本, 我们可以做一些评估, 是否可以升级到对应的版本. 不止是工具链，其他依赖可能也涉及，但 RV...
> my thought/question is just if any "old world" compiler would identify itself as gcc 12 (or higher), or if that is a clear identification of "new world". And are...
@martin-frbg: Thanks for the help! I'll do the rebase later (busy at `$DAY_JOB` and focusing on upstreaming of the Linux/LoongArch port lately). I hope to finish this in this week.
Very much drowned by day job, I'll return to this later this week.
I've seen a fatal error but `make` completed nevertheless, interesting... ``` OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE) OS ... Linux Architecture ... loongarch64 BINARY ... 64bit C compiler ......
Hmm, there are some more errors. I've attached the full `make` output (not the first invocation so the log is not flooded with gcc calls) below. [make-20220729.log](https://github.com/xianyi/OpenBLAS/files/9218150/make-20220729.log)
Okay I'll send an updated revision hopefully today. Thanks for reviewing.
Much time has passed after the initial porting, I can't recall the fine details but I thought this behavior is consistent with original `autojump` so I even wrote the test...