Bug#1028654: dpkg: add loongarch64 architecture GNU triplet

[Guillem Jover]

On Sat, 2023-01-14 at 18:29:12 +0800, 张丹丹 wrote:
> Package: dpkg
> Version: 1.21.17
> Severity: wishlist
> Tags: patch
> User: debian...@lists.debian.org
> Usertags: loongarch64

> - I have added loongarch64 architecture GNU triplet to match the change in gcc-12.
> This patch can fix problems when cross-building and ensure gcc and dpkg use matched combination.
> Please consider the patch attached. (Reference from raben...@gmail.com)

Hmm, why was the triplet changed? I mean it's not been too long since
it got added into dpkg, and supposedly backwards compatibility should
not be much of an issue (?), but why is this really necessary?

What does the unqualified triplet stand for now, which is supposed to
be considered the baseline?

> - The change of gcc-12 for loongarch64, please see the bleow BugID request:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027278

> - Are there any missing? Please tell me.

See above. Also the patch (if it ends up being really necessary) does
not look entirely correct, the entries should be placed before the
more general match. Attached the modified one which now also passes
the test suite («make check»).

Thanks,
Guillem

[Guillem Jover]

Hi!

The reasons for changing the ABI at this point in time are still not
very clear to me (Helmut mentioned some reasons though), and the fact
that this was submitted to the gcc package before any discussion seems
all wrong. :/

This divergence between dpkg and at least gcc is currently breaking
rebootstrap, and the uncertainty of this all is currently blocking
a pre-approval request for the pending dpkg release. So what I think
I'm going to do is back out (revert) the loong64 support for now, and
once this is all clarified I'm happy to reintroduce it again. I'm
planning to do at least another release after the upcoming one before
the Debian release, where this could be readded.

I'll be sending the pre-approval request later today.

Thanks,
Guillem

[Guillem Jover]

On Tue, 2023-01-24 at 11:28:55 +0100, Guillem Jover wrote:
> The reasons for changing the ABI at this point in time are still not
> very clear to me (Helmut mentioned some reasons though), and the fact
> that this was submitted to the gcc package before any discussion seems
> all wrong. :/
>
> This divergence between dpkg and at least gcc is currently breaking
> rebootstrap,

(Sorry, this should have said, "it broke rebootstrap (but is now
worked around)", thanks to Helmut for spotting that.)

[zhangdandan]

Dear maintainers,
    Happy new year. Thank you for your reply.
We are carefully considering the Debian Multiarch Define of Loongarch64.

Thanks,
Dandan Zhang

[zhangdandan]

Hi maintainers,

Here are some explanatory notes on the loong64 port's multiarch tuples
issue.

Previously, in order to be consistent with the GCC upstream and
Toolchain Conventions, the multiarch tuple "loongarch64-linux-gnuf64"
[1] was used for the LP64D ABI.
We then restored the multiarch tuple used by the Debian gcc package from
"loongarch64-linux-gnu" to "loongarch64-linux-gnuf64"[2].

Unfortunately, we didn't realize that the Debian multiarch tuples
document [3] predated the gcc multiarch tuple definitions [1].
Thanks for the feedback [4] and helmut's help, we have reconsidered the
matter surrounding Debian's multiarch tuple definitions.

We decide to use "loongarch64-linux-gnu" as the value of the Debian
loong64 port's multiarch tuple.
The reasons for using "loongarch64-linux-gnu" are as follows:

Firstly, we note that many of the major architectures use the -gnu style
in Debian [3].

- amd64: x86_64-linux-gnu
- arm64: aarch64-linux-gnu
- riscv64: riscv64-linux-gnu

Secondly, "loongarch64-linux-gnu" is also consistent with upstream
LoongArch gcc's latest change (replacing "loongarch64-linux-gnuf64" with
"loongarch64-linux-gnu") [5][6] and the current revision of LoongArch
Toolchain Conventions [7].

Please reconsider the loong64 patch (with "loongarch64-linux-gnu") to dpkg.

Your opinions are welcome.

[1]:
https://github.com/gcc-mirror/gcc/commit/b44786f64019e7#diff-a9fbd3415f77b73e7a86c365707a79c6d60311ce5b81fad000a15f970b18fedfR4971
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027278
[3]: https://wiki.debian.org/Multiarch/Tuples
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028654
[5]: https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612272.html
[6]: https://github.com/gcc-mirror/gcc/commit/017849d9d88f02
[7]:
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html#_gnu_target_triplets_and_multiarch_specifiers

Thanks!
Dandan Zhang

[Guillem Jover]

Hi!

On Mon, 2023-02-20 at 21:30:14 +0800, zhangdandan wrote:
> We decide to use "loongarch64-linux-gnu" as the value of the Debian loong64
> port's multiarch tuple.
> The reasons for using "loongarch64-linux-gnu" are as follows:
>
> Firstly, we note that many of the major architectures use the -gnu style in
> Debian [3].
>
> - amd64: x86_64-linux-gnu
> - arm64: aarch64-linux-gnu
> - riscv64: riscv64-linux-gnu
>
> Secondly, "loongarch64-linux-gnu" is also consistent with upstream LoongArch
> gcc's latest change (replacing "loongarch64-linux-gnuf64" with
> "loongarch64-linux-gnu") [5][6] and the current revision of LoongArch
> Toolchain Conventions [7].

Ok, so then just to confirm, the support that was already in dpkg's
git and that got reverted should be fine again. If so then I'm going
to revert commit f9187c8b13478824c9eff73c92a084cc50c34cad to restore
the previous code, and then request a pre-approval from the release
team in a couple of days.

Thanks,
Guillem