Adjust the Multiarch Specifier #80
Conversation
* Changes - Replace loongarch64-linux-gnuf64 with loongarch64-linux-gnu. - Remove all loongarch32 multiarch specifiers. * Several reasons for making the changes - "f64" indicates the generic purpose ABI variant. So "gnuf64" seems unnecessary - can be replaced with "gnu". We see a related discussion in llvm [1]. And gnu is adopted by many popular archs [2]. - There is no 32-bit LoongArch chips and operating systems at present and we are not sure whether 32-bit hardware is allowed or necessary to support 64-bit floating-point. So it's better not define the tuples for now. [1]. https://reviews.llvm.org/D135751#3851867 [2]. https://wiki.debian.org/Multiarch/Tuples
|
You're basically overturning the previous consensus reached at #24 (actually in that thread, people including me would have liked if it stayed Although reinstating Relevant IRC log: In conclusion: I strongly suggest to just stick to the current state of things and settle on
Otherwise, you should at least:
And months of efforts would still be wasted, requiring much rework. |
|
cc @scylaac @xry111 @yetist @chenhuacai @ChenghuaXu (participants of #23 #24 and #25) Also I've noted that at least LLVM and systemd would suffer from code churn if we're to abolish |
|
Regarding removal of ILP32 multiarch IDs: It's indeed true that no LA32-only chip is generally available at the moment, but some work has already been done for ILP32 support, as can be seen in LLVM/Clang. And it's not like the future tuples that would get added again after appearance of LA32 chips would change much from the present definition, so again IMO it's avoidable code churn that's best to just leave out for now. And, as for your doubt that you "are not sure whether 32-bit hardware is allowed or necessary to support 64-bit floating-point", here's excerpt from the LoongArch Reference Manual, Chapter 3:
So either you don't have to worry about this non-existent problem, or tell your documentation and ISA guys to amend the manual... |
And GCC. If I read GCC build system code correctly:
The inconsistency can be trivially fixed after a final decision about using or not using |
Well, not a suffer from code churn actually, but "the inconsistency can churn other code". |
Some off-topic trivia: LA32 + FP64 reminds me some old time when people (over)uses floating point operation to speed up the integer arithmetic in range |
|
|
龙芯员工代表龙芯公司说的话语： 一切的讨论都是无效的 只有龙芯的最终决定才行 我只能说 之前那些讨论有什么用呢 龙芯开会定不是挺好的嘛 |
And some triples I see in llvm: |
这个无所谓，主要问题是 我来说一下问题背景，multiarch 这个东西事为了修饰文件/目录名，从而让发行版更容易支持多个 ABI。比如在 x86 上一些发行版会有 Python 也开始加这东西： 然后还有个东西叫 PyPI，就有个什么结果呢，你的发行版的 Python 给的 multiarch 目录名如果和 PyPI 不一致的话 其实意见不一致的话可以每个发行版自己搞，工具链 patch 一下，Python patch 一下，大概就行了？(就是工具链按自己搞法，Python 和 PyPI 一致。) 这又不是啥神秘的难搞的东西，改个搜索路径很 trivial 的。 至于“不同发行版间兼容性”这个概念早就已经咩了，不用管，不然 docker 这种东西也不会大行其道。 |
https://reviews.llvm.org/D142685 |
This actually depends on the host triple i.e. For example on my (migrated for Toolchain Conventions compliance) box: |
这个东西理论上还真不是龙芯能决定的，我很确定 Intel 没有决定 x86_64-linux-gnu，RISC-V 我大概搜了一下 multiarch tuple 也不是 foundation 定的，基本上就是发行版想怎么样怎么样。甚至就算龙芯强推到上游也就是一行 sed 或者几行 patch 的事情，我记得 Debian/Ubuntu 编译 GCC 时候打 multiarch 补丁打了好几年了。 |
基本赞同，按照发行版Debian惯例，新的架构还是优先使用gnu更好一些。
目前真正推到社区的发行版好像还没有？自己私下做的，如你所说打几个补丁就好了。 |
不完全，我们当初《工具链约定》写全 multiarch ID 的 float ABI suffix 也是形式对称，显式、直观提供更多信息。不至于因为“最常用”就使得 multiarch ID 外形的不对称合理化。 另外见前边我贴的 12 月 IRC log，旧世界已经用了
如前所述 Gentoo 已经达到官方正式支持，且早已准备按照《工具链约定》修正先前的做法。（Gentoo 采用 不过 Gentoo 本身不采用 multiarch 的目录布局，所以这边的改动也只是影响跟 Debian 互操作而已。 |
根本不是打几个补丁的事 已经反复推翻了两次 deepin这边都快能启动了 |
这个应该不是问题吧？社区中真的存在什么新旧世界之分吗？个人观点，还是按照Debian的惯例更合理一些（好像没有哪个架构上来就加了万恶的尾巴^_^）
同样道理，社区中还没有哪个发行版使用了gnuf64，即使有也只是影响与Debian的互操作而已。 |
有啊 如果有新世界装了loongnix/uos/kylin的deb包 还可以当跨新旧世界的兼容方案 在不同的目录里安装 而且将来适配的时候 给装旧世界的包留有余地 |
|
没看完前面的的对话。只想说，制订 specification 是要负起历史责任的，应该尽量保持向前兼容 |
我意思你把所有出现 loongarch64-linux-gnu 的地方都加个 f64，然后已经编译的就不用动了。硬编码 multiarch tuple 的地方不多，一般都是用 在这个 LSB 已经死了，大家群魔乱舞地搞静态编译/系统镜像的时代不同发行版根本就不可能互操作，所以我对这个问题不站立场，按我们 LFS 的话来说 your distro your rules，他非要写进文档你不管他就行了，只要你自己发行版内部是一致的就行。 |
以上的那些顺便验证了f64在debian上工作良好 根本就不会遇到所谓的技术难题
改f64中涉及修改的包的列表 |
clang已经从16开始废弃了对 |
|
龙芯不回应的approve是在是否是想在这件事上装死糊弄过去？ |
|
你们没法站出来正面回应一下？这件事对于社区来说影响太恶劣了，在这装死只会让事情更加恶化。 |
|
补充2023年1月30日 达成的第二次共识（社区讨论群的社区人员达成共识 龙芯方面未做表态）：
|
musl 的部分倒是：
所以去掉没问题，不会伤到共识。 本次讨论的焦点是 2 年前讨论形成的大家不反对的共识（LP64D ABI 的 multiarch ID 仍然带 |
There was a problem hiding this comment.
很遗憾没能参与到 #29 的讨论中。鉴于Debian wiki已经是loongarch64-linux-gnu，我同意本次修改。@MaskRay 觉得怎么样？
|
|
考虑到商业因素之类的东西 关于debian wiki相关描述的原因补充解释一下 @wangleiat @SixWeining |
|
https://wiki.debian.org/Multiarch/Tuples 很多triples用 我理解的Debian multiarch的问题是 |
感谢披露商业因素。您这条回复很勇敢。 |
This is without the commercial reasons (see the linked PR) to hopefully make the change more palatable to the angry mob of unknowing readers. For the record: this is DEFINITELY NOT the full reason behind the closed-door decision. But this is about as close as we community people can get in persuading the depressed ourselves, and about all I can disclose after having multiple private conversations with relevant parties, without inflicting damage to anyone at Loongson or Loongson as a whole (we don't really want to openly criticize Loongson for tweaking a 1-year-old document for primarily commercial reasons, but again it's arguably fair for a privately-controlled ISA to evolve like this). See: loongson#80
仔细想了下，很不幸，这有风险： 我们无法控制龙架构的用户不向真正 PyPI 传包（其实向你们的 PyPI 镜像传包也一样），所以可预见的将来一定会同时有新世界和旧世界上构建的 wheel 被传上。目前上游在 wheel 的命名上没有感知龙架构的新旧世界，所以两个世界做的 wheel 名字目前来看一定是一样的。 这样一定会出现用户装上异世界 wheel 且流程不马上死掉的情况，失败会发生在更往后的运行时某时刻。因为 Python 原生扩展不是完整 POSIX 程序，所以没踩到新旧世界不兼容点（如信号处理、裸的 fstat 等系统调用之类）的那些扩展不会出事，其他的会在被调用的时候炸。虽然我不是很确定存不存在这样的扩展（因为新旧世界不兼容之一是 glibc 符号版本，其实想像不到会有不依赖 libc 符号的 Python 扩展，这样的话 |
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf". Before this commit,
"--target=loongarch64-linux-gnu --with-abi=lp64s --disable-multilib"
will produce wrong result (loongarch64-linux-gnu).
A recent LoongArch psABI revision mandates "loongarch64-linux-gnu" to be
used for -mabi=lp64d (instead of "loongarch64-linux-gnuf64") for some
non-technical reason [1]. Note that we cannot make
"loongarch64-linux-gnuf64" an alias for "loongarch64-linux-gnu" because
to implement such an alias, we must create thousands of symlinks in the
distro and doing so would be completely unpractical. This commit also
aligns GCC with the revision.
Tested by building cross compilers with --enable-multiarch and multiple
combinations of --target=loongarch64-linux-gnu*, --with-abi=lp64{s,f,d},
and --{enable,disable}-multilib; and run "xgcc --print-multiarch" then
manually verify the result with eyesight.
Ok for trunk and backport to releases/gcc-12?
[1]: loongson/LoongArch-Documentation#80
gcc/ChangeLog:
* config.gcc (triplet_abi): Set its value based on $with_abi,
instead of $target.
(la_canonical_triplet): Set it after $triplet_abi is set
correctly.
* config/loongarch/t-linux (MULTILIB_OSDIRNAMES): Make the
multiarch tuple for lp64d "loongarch64-linux-gnu" (without
"f64" suffix).
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf". Before this commit,
"--target=loongarch64-linux-gnu --with-abi=lp64s --disable-multilib"
will produce wrong result (loongarch64-linux-gnu).
A recent LoongArch psABI revision mandates "loongarch64-linux-gnu" to be
used for -mabi=lp64d (instead of "loongarch64-linux-gnuf64") for some
non-technical reason [1]. Note that we cannot make
"loongarch64-linux-gnuf64" an alias for "loongarch64-linux-gnu" because
to implement such an alias, we must create thousands of symlinks in the
distro and doing so would be completely unpractical. This commit also
aligns GCC with the revision.
Tested by building cross compilers with --enable-multiarch and multiple
combinations of --target=loongarch64-linux-gnu*, --with-abi=lp64{s,f,d},
and --{enable,disable}-multilib; and run "xgcc --print-multiarch" then
manually verify the result with eyesight.
[1]: loongson/LoongArch-Documentation#80
gcc/ChangeLog:
* config.gcc (triplet_abi): Set its value based on $with_abi,
instead of $target.
(la_canonical_triplet): Set it after $triplet_abi is set
correctly.
* config/loongarch/t-linux (MULTILIB_OSDIRNAMES): Make the
multiarch tuple for lp64d "loongarch64-linux-gnu" (without
"f64" suffix).
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf". Before this commit,
"--target=loongarch64-linux-gnu --with-abi=lp64s --disable-multilib"
will produce wrong result (loongarch64-linux-gnu).
A recent LoongArch psABI revision mandates "loongarch64-linux-gnu" to be
used for -mabi=lp64d (instead of "loongarch64-linux-gnuf64") for some
non-technical reason [1]. Note that we cannot make
"loongarch64-linux-gnuf64" an alias for "loongarch64-linux-gnu" because
to implement such an alias, we must create thousands of symlinks in the
distro and doing so would be completely unpractical. This commit also
aligns GCC with the revision.
Tested by building cross compilers with --enable-multiarch and multiple
combinations of --target=loongarch64-linux-gnu*, --with-abi=lp64{s,f,d},
and --{enable,disable}-multilib; and run "xgcc --print-multiarch" then
manually verify the result with eyesight.
[1]: loongson/LoongArch-Documentation#80
gcc/ChangeLog:
* config.gcc (triplet_abi): Set its value based on $with_abi,
instead of $target.
(la_canonical_triplet): Set it after $triplet_abi is set
correctly.
* config/loongarch/t-linux (MULTILIB_OSDIRNAMES): Make the
multiarch tuple for lp64d "loongarch64-linux-gnu" (without
"f64" suffix).
(cherry picked from commit 017849d)
Multiarch tuple will be coded in file or directory names in
multiarch-aware distros, so one ABI should have only one multiarch
tuple. For example, "--target=loongarch64-linux-gnu --with-abi=lp64s"
and "--target=loongarch64-linux-gnusf" should both set multiarch tuple
to "loongarch64-linux-gnusf". Before this commit,
"--target=loongarch64-linux-gnu --with-abi=lp64s --disable-multilib"
will produce wrong result (loongarch64-linux-gnu).
A recent LoongArch psABI revision mandates "loongarch64-linux-gnu" to be
used for -mabi=lp64d (instead of "loongarch64-linux-gnuf64") for some
non-technical reason [1]. Note that we cannot make
"loongarch64-linux-gnuf64" an alias for "loongarch64-linux-gnu" because
to implement such an alias, we must create thousands of symlinks in the
distro and doing so would be completely unpractical. This commit also
aligns GCC with the revision.
Tested by building cross compilers with --enable-multiarch and multiple
combinations of --target=loongarch64-linux-gnu*, --with-abi=lp64{s,f,d},
and --{enable,disable}-multilib; and run "xgcc --print-multiarch" then
manually verify the result with eyesight.
[1]: loongson/LoongArch-Documentation#80
gcc/ChangeLog:
* config.gcc (triplet_abi): Set its value based on $with_abi,
instead of $target.
(la_canonical_triplet): Set it after $triplet_abi is set
correctly.
* config/loongarch/t-linux (MULTILIB_OSDIRNAMES): Make the
multiarch tuple for lp64d "loongarch64-linux-gnu" (without
"f64" suffix).
Changes
Several reasons for making the changes
[1]. https://reviews.llvm.org/D135751#3851867
[2]. https://wiki.debian.org/Multiarch/Tuples