Hi!
This week has been mostly dedicated to QtWebEngine, a package that bundles Chromium, which in turn bundles a bunch of libraries (:D). It took a lot longer than I initially thought while planning GSoC, but nonetheless I finished all my weekly goals. Those being (1) get most of my previous work upstreamed & (2) get qutebrowser running fine. I’ve been writing daily blogs up until Thursday, since it would just be: “yesterday I did $thing, today I also did $thing… aaand tomorrow I’ll continue with $thing”. But I’ll continue with them next week.
To start I looked at other musl distributions like Alpine and Void to see if they had packaged QtWebEngine, and yes, Alpine had 24 patches, and Void, 36. Both of these distros used version 5.15.3, while Gentoo was at 5.15.5. So instead of just blindly applying each patch I ran the build until it failed, and then grepped for a patch that looked applicable. This worked fine most of the time, but sometimes I needed to do some manual patching as well. This approach also made sure I only patched things that still needed patching.
The problem with Alpine patches are that they are only focused on getting the package to work with musl. Sometimes that means even less portability, and ugly workarounds are often used. The patches are most of the time not commented either, leading to a lot of confusion, like with the “musl-hacks” patch (https://git.alpinelinux.org/aports/tree/community/qt5-qtwebengine/musl-hacks.patch). This patch has to do with msghdr being filled with padding in musl, which does not play nice with initializer lists.
diff --git a/src/3rdparty/chromium/net/socket/udp_socket_posix.cc b/src/3rdparty/chromium/net/socket/udp_socket_posix.cc
index dbc8c5aaf..077bbde33 100644
...
- msgvec->push_back({{nullptr, 0, &msg_iov[j], 1, nullptr, 0, 0}, 0});
+ msgvec->push_back({{nullptr, 0, &msg_iov[j], 1, 0, 0, 0}, 0});
...
>”POSIX clearly specifies the type of msg_iovlen and msg_controllen, and
>Linux ignores it and makes them both size_t instead. to work around
>this we add padding (instead of just using the wrong types like glibc
>does)”
musl’s msghdr:
struct msghdr {
void *msg_name;
socklen_t msg_namelen;
struct iovec *msg_iov;
#if __LONG_MAX > 0x7fffffff && __BYTE_ORDER == __BIG_ENDIAN
int __pad1;
#endif
int msg_iovlen;
#if __LONG_MAX > 0x7fffffff && __BYTE_ORDER == __LITTLE_ENDIAN
int __pad1;
#endif
void *msg_control;
#if __LONG_MAX > 0x7fffffff && __BYTE_ORDER == __BIG_ENDIAN
int __pad2;
#endif
socklen_t msg_controllen;
#if __LONG_MAX > 0x7fffffff && __BYTE_ORDER == __LITTLE_ENDIAN
int __pad2;
#endif
int msg_flags;
};
(https://git.musl-libc.org/cgit/musl/tree/include/sys/socket.h#n22).
Looking at the structure we can clearly see that the fifth member of msghdr will be int __pad1 on x86_64, which explains why implicitly converting will fail. I first thought this was something similar to the “NULL being defined as nullptr in >=c++11 in musl”-problem, but it turns out it was not, and it took me a while to figure out what was wrong by just getting a conversion error from the initializer list. I wanted to properly comment on every patch, and this was one example of a patch that took me some time to fully grasp even though the issue was already solved.
Both Alpine and Void have musl compatibility like these as well, https://blogs.gentoo.org/gsoc/2022/07/10/thoughts-about-musl-standalone-compatibility-packages-for-gentoo-controversial/. Which means that some glibc functionality will “just work” there. Examples of this in QtWebEngine is queue.h and cdefs.h. As said in the blog post: packages that rely on these should be fixed/reported upstream, but standalone libraries can be included in Gentoo for users that want to compile third party software without the hassle. In the queue.h case I just __has_include:ed queue.h and if it wasn’t there then use a compatibility header patched to the source tree. A prettier way would’ve been to use QMake to check for it, but as QMake is being replaced by CMake it made sense not to bother with it.
Because QtWebEngine takes a very long time to compile, and I did it over and over A LOT this week, I spent my time waiting reading more of the Gentoo devmanual. I learnt a lot regarding ebuild development but also some other Gentoo/portage stuff :).
Next week I’ll get the QtWebEngine patches into ::gentoo and see what I can upstream, I’ll also run test suites for core KDE applications and fix them if the tests do not pass. The hard part about upstreaming QtWebEngine patches is that it bundles an ancient version of Chromium (87), and Chromium itself bundles libraries that are broken, so getting patches to land in QtWebEngine will take a very long time. Sam thinks a better place to focus is KDE’s Qt5PatchColletion, and then upstream things that make sense.