Dear maintainers,

qt6-webengine succeeded building with the attached patch on my QEMU riscv64
machine, until dpkg-gensymbols complains about symbol difference (see [1]).

The patch is partly taken from openSUSE [2], consisting mostly of modifying
macro conditions so that the source code recognizes riscv64 architecture.

If the patch is acceptable, could you help correct those symbol errors? If
more help is needed, please let me know.

Cheers,
Eric

[1]: https://gist.github.com/hack3ric/694b90b8b9ea001f976269c4a2440b6e
[2]: https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/chromium

Attached is the generated symbol diff using pkgkde-symbolshelper.

Cheers,
Eric

Hi Eric!

The problem are these three symbols gone missing:

lisandro@gryffindor:/tmp/tmp.XxK8t7vqRk$ grep MISS * | grep -v optional
+#MISSING: 6.4.2+dfsg-0rc0-2# _ZTVSt15_Sp_counted_ptrIPSt6vectorIcSaIcEELN9__gnu_cxx12_Lock_policyE2EE@Base 6.2.2
+#MISSING: 6.4.2+dfsg-0rc0-2# _ZTVSt15_Sp_counted_ptrIPSt6vectorIhSaIhEELN9__gnu_cxx12_Lock_policyE2EE@Base 6.2.2
+#MISSING: 6.4.2+dfsg-0rc0-2# _ZTVSt19_Sp_counted_deleterIPcSt14default_deleteIA_cESaIvELN9__gnu_cxx12_Lock_policyE2EE@Base 6.2.2

They are entries to the vtable which the compiler is free to generate and they should be marked as optional. NOn the less pkgkde-symbolshelper [1] should handle them, at very least marking them as not available on RISC-V.

That being said, what are the chances of those patches reaching upstream? I guess chrome upstreams would love to have such a patch for RISC-V.

[1] <https://qt-kde-team.pages.debian.net/symbolfiles.html[1]>

See if you can make sense of it, else feel free to contact me again, CCing me.

Kinds regards, Lisandro.

--------
[1] https://qt-kde-team.pages.debian.net/symbolfiles.html

Hi Lisandro,

I changed SymbolsHelper-Confirmed header to "6.4.2 !riscv64" and
managed to
generate symbol files without MISSING. Please check if there are any
errors.

As for the upstream: Chromium's Linux build machines uses Debian stable
(as can
be seen in their build script [1]), so unless riscv64 makes it to
Debian's
release architectures, they are not willing to merge patches for riscv64
support. Adding Chromium to Debian's riscv64 architecture would be a
step
forward ;)

(I'm yet to submit the patch to Debian's chromium package because they
also
added patches for ppc64el support, which is similar to our situation. I
may need
to manually modify the macro conditions so that they work together)

Cheers,
Eric

[1]:
https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator-bullseye.sh

Hi!

El sáb, 11 de feb. de 2023 09:53, Eric Long <i@hack3r.moe> escribió:

Well, that's not the real solution ;-) The idea is that you manage those
symbols. It's not easy at first, but you get used to it.

Oh, I see. Chicken and egg problem. Ok, in this case we need to go forward
in some way.

Please do. I'll see to add the patch as soon as possible.

Thanks for your work Eric! Whenever I can, and if I do not forget, I'll
show you how to deal with symbols files

We believe that the bug you reported is fixed in the latest version of
qt6-base, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1030895@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org> (supplier of updated qt6-base package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 20 Feb 2023 16:54:52 -0300
Source: qt6-base
Architecture: source
Version: 6.4.2+dfsg-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Closes: 1030895
Changes:
 qt6-base (6.4.2+dfsg-4) unstable; urgency=medium
 .
   * Team upload.
   * Workaround wrong path in CMake file, Qt6::qmake IMPORTED_LOCATION by
     modifying the path (Closes: #1030895).
     Thanks Helmut Grohne and Dmitry Shachnev for the bug and solution.
Checksums-Sha1:
 debf375868c7304aa69c6e51d9264433da712de6 4859 qt6-base_6.4.2+dfsg-4.dsc
 11bc003ea2f6d34dd522db8a62e791b7a2eb3bfd 174536 qt6-base_6.4.2+dfsg-4.debian.tar.xz
 1570bc332d4bf43e33c6d355412960af468b31bc 18580 qt6-base_6.4.2+dfsg-4_source.buildinfo
Checksums-Sha256:
 6c83ad5b165a9724ccf12118bb28c91bf30aeff43eeef496577684e229ebe9d9 4859 qt6-base_6.4.2+dfsg-4.dsc
 88fd40d35cdca3f8be9a160792db85db5d54d0f4534faaa17531517430a49bdd 174536 qt6-base_6.4.2+dfsg-4.debian.tar.xz
 39d911ecb75206a8b32ceb3e386f0edd7d29cb1ed21122355187655852ce2064 18580 qt6-base_6.4.2+dfsg-4_source.buildinfo
Files:
 8bc81e2930f3b9cf7e306e5cb2882b22 4859 libs optional qt6-base_6.4.2+dfsg-4.dsc
 7750e8ceed85877b5adde61b360c3447 174536 libs optional qt6-base_6.4.2+dfsg-4.debian.tar.xz
 96d5f966512a8a4a3845fb5940669f9a 18580 libs optional qt6-base_6.4.2+dfsg-4_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEEt36hKwjsrvwSzE8q2RfQGKGp9AFAmPz0EUUHGxpc2FuZHJv
QGRlYmlhbi5vcmcACgkQq2RfQGKGp9AArxAAhpzYhawatSpgRJiMK5EDFtxZVrJT
3B9pHDiS/29jk+Y5IkwLDDDA6hdsa59pNGxUTcrpq529U3cBTVzVMY3ygojNdcoD
c6qKwvt5OGbEGHI7X52RteiTEA2r0ve3ZitdgIqsEK/WctaVqnbZNdPAqsm7Skuz
PD+9CLpwjblimvaDuoDL+VoimlPkXfxC1L89/jNKm/KtgH73ZxCWhyGS344gyREH
2BjBJFc44g2cwAigYpciku6FFXWqXqkG9jqwKeky+e+/FeGxko/3Fop2PxnXtDN4
X2raW75qSpuiZ95RXWqTnbUKxoS5a49tb6ukE64s6jPyz5ON8aOJpK4RwblFq1EP
hQbJEQdsY2dVpLWp//87OLkft/3imUGGUVb+dHvdz3E0VYU2ddLTaefzKk6odX5S
/L4YmzVyaZw0WhIBt/5hpHpn9vdWCFUt5BDMcU/VqV2ijoqOR62R7KxR9A7qQXm0
gaLWrebW3BAGDDHzfHj9lDNMIwl96yKCNyOIonQ2x08VXSBfTevVbPXBv7sBzGKb
K7qnPU84RWa1MY68N4S0FE048WGm0L9OlHWUjqMs1ZQdWxDAAjhojgkfaRJSg5jn
fdzuSwRHS/n6emanym7Ym+HiPmUepBcie/3J6WZ3vPTB/kStnPj4PbonOrCqluKk
khmFM/YLvu3FC7U=
=AGIM
-----END PGP SIGNATURE-----

Hi,

Many thanks Eric for working on this.

I noticed this[0]:
```
As for the upstream: Chromium's Linux build machines uses Debian stable
(as can
be seen in their build script [1]), so unless riscv64 makes it to
Debian's
release architectures, they are not willing to merge patches for riscv64
support. Adding Chromium to Debian's riscv64 architecture would be a
step
forward ;)
[1]: https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator-bullseye.sh
```
IIRC, the scripts[1] should be used to cross build Chromium.:)
In fact, Chromium has accepted some patches that support riscv64.

I have updated the symbols file of qt6-webengine based on Eric's patch
and I can built it on my local riscv64 qemu. I believe the package can
be built on Debian riscv64 buildd machines(Unmatched board) also.

Could you try it on the next upload?

Thanks again for all here.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030895#20

Hi,

On Sat, 15 Apr 2023 23:32:53 +0800 Bo YU <tsu.yubo@gmail.com> wrote:
[...]

Before we can consider applying this patch, there is the question of
maintenance. I am not very keen on having a 12.000-line patch to
maintain for qtwebengine which in itself is already hard to maintain.

Just for fun, I tried to apply the patch to the recently released Qt
Webengine 6.5.2 and unfortunately, a significant number of hunks from
various subpackages could not be applied and would have to be
readjusted. I'm afraid we'll run into the very same problem for each new
Qt release. And that makes such a patch unsuitable.

So, unless you have an idea how to avoid running into this problem...

Do you know if upstream (either Qt or Google) would have any interest in implementing
riscv64 support?

Given Google’s current focus on RISC-V for Android, and that fact that the Chromium
codebase also builds the Android version of Chromium, I think they might be open to it.

https://arstechnica.com/gadgets/2023/01/google-announces-official-android-support-for-risc-v/[1]

And if Google adds support to Chromium, it wouldn’t take nearly as much effort for Qt to
support it in WebEngine.

--------
[1] https://arstechnica.com/gadgets/2023/01/google-announces-official-android-support-for-risc-v/

Hi！

I understand the situation and I am packaging the Debian riscv64 Chromium.
The original patch from OpenSUSE and I am not sure they why not to
push these changes to upstream.:)
This will benefit all distros.

Sure, I will give it a try to upstream if there is allowed(Chromium).

BR,
Bo

Hi!

Thanks for the heads up. Maintaining such a large patch is quite unsuitable.
Packaging Chromium has the same issue, but it has fewer lines patch than here.
The major issue is to have conflict with ppc64's patch.

It is wise to push these changes to Chromium upstream. But it will
cost a long time maybe.
Okay, let me think about a workaround before upstream supports this.
Thanks again.

Bo

Add support to Chrome/Chromium and the rest just happens.

Hi!
...

Let's start here again, okay? :)

I just refactor these patches, which should not affect building of
other architectures except riscv64.

I seperated the riscv64 patchset into riscv64/ under debian/patches only
can be applied when build on riscv64 machines. In order to do this, I
bring a helper script to automatically scan all the riscv64 patches
and merge them with the original series files.

Now these riscv64 patch are these:

```
ls debian/patches/riscv64/
001-3rd_abseil.patch    005-component-update_client.patch  010-3rd_highway.patch  014-3rd_dawn.patch    019-sandbox.patch
002-3rd_angle.patch     006-3rd_crashpad.patch             011-3rd_libaom.patch   015-3rd_webrtc.patch
003-base.patch          007-3rd_dav1d.patch                012-3rd_libvpx.patch   016-qt-cmake.patch
004-3rd_breakpad.patch  009-skia.patch                     013-3rd_lss.patch      018-3rd_ffmpeg.patch
```
There is only 016-qt-cmake.patch need to support riscv64 from QT itself.
Others are all patches to support riscv64 on Chromium.

I'm not sure QT 6.5.2 will bind to which version of Chromium. If is 112,
the quantities of these patches will decrease about a half from my port
experience about Chromium. But unfortunately, the total of lines of
patches will will not be reduced by much(mainly due to ffmpeg and sanbox
cause this). But the fact also show that the chromium upstream support
riscv64 is a work in progress.

I have some clean work which still need to finish, like temporary file and
unnecessnary comment which help to debug. But I am appreciated that you
can comment on the solution given on the qt6-webengine is a very key
package on Debian.

Thanks.

Hi,

On 21/11/23 06:06, Bo YU wrote:
[snip]

And still we have a 14k+ lines debdiff to apply. My apologies, this is a
huge NACK. Get it supported by upstream first and then we can talk.

Hi!

On Fri, Nov 24, 2023 at 1:33 AM Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> wrote:

The good news is that there is making an update for Chromium upstream, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051998#72

If everything is okay and Chromium can accept these patches but qt6
upstream can pick the Chromium which has supported riscv64 will wait a
long time I think.

Thanks  again~

BR,
Bo
(BTW, if anyone need these qt6-webengine riscv64 package, please to
see here: http://www.riscv-dev.tech:63015/qt6-webengine/)

Bo,

Thank you for all your effort to make this happen.

I can’t speak for all of the developers who work on the Qt WebEngine packages, but I can
tell you that generally there is a much greater willingness to backport patches that have
landed in Chromium but have not yet made it to upstream Qt WebEngine (but will
eventually get there) than there is to patch Qt WebEngine in a manner that has not yet
been implemented in upstream Chromium.