Hi! This is my weekly report for week 4 of Summer of Code. This week I’ve done some more ebuild development and fixed some more build-time bugs for various packages. We’ve also discussed adding *-standalone compatibility libraries for musl.
To start with I tried some gaming on my musl machine! I got both gamescope and gamemode running with some work. I made an ebuild for gamescope (that I forgot to publish, will do soon). Gamemode needed some fixing so I sent a patch upstream [1]. After that it was mostly plug-and-play with Flatpak Steam and Lutris. I also tried some native gaming with Super Tux Kart, Super Tux, and fheroes2. This was on the weekend but I still think it’s worth mentioning here.
The next big thing I did this week was packaging a replacement for execinfo [2]. Execinfo is used by applications for self-debugging and provides functions for backtraces [3], these symbols are provided by glibc but not musl and the reasons as to why are listed here [4].
A replacement from a FreeBSD developer is available as “libexecinfo”, but just installing it does not solve every problem because some programs incorrectly link to it. For example qtcore checked for the H_HAVE_EXECINFO header, and then linked with -lexecinfo only if it was running on BSD. Similar story with sci-libs/metis, but that just assumed execinfo symbols were provided bu glibc unconditionally. What they should be doing is searcing for execinfo symbols with AC_SEARCH_LIBS (autotools) or similar for other build systems. An even better solution is to use pkg-config files, so I started with creating a .pc file in the source tree by hand, but after chatting with Sam we thought it was better to just add meson as a build system, and let it create the .pc for us. An example can be seen here [5]. QtCore which I ran across two weeks ago was just patched by forcing the execinfo.h check to false because QMake is being phased out for CMake and we thought it wasn’t worth spending time properly patching it upstream. My personal favorite solution is to just use GDB :).
Another thing worth discussing is the addition of more *-standalone libraries for Gentoo musl. A problem which both me and listout run into a lot is error.h not being defined. Rich, the maintainer of musl suggests that [6] adding a standalone error.h header into the source trees of applications that use error.h is a reasonable action to take. But the problem here is that we’ll need to patch every application to do that, and even then it’s not a pretty solution. Ideally we want all applications to use standards-defined method of handling errors, like fprintf(stderr, …) + exit(status), or the C89 perror() function. This is a very dividing topic, but since both Void [7] and Alpine [8] provide standalone compatibility packages for this exact issue we felt like it made sense. A good middle ground was to include these compat libraries but still open issues/PRs to upstreams to stop using error.h. This of course applies to all similar issues (not just error.h). Here’s an example ebuild of error.h standalone: https://github.com/alfredfo/catcream_repo/blob/master/sys-libs/musl-compat-error/musl-compat-error-1.0.0.ebuild. plocate is an example of a package that used error.h and I patched that with fprintf + exit this week.
I also spent a lot time fixing two non-issues, but “fixing” the first one was very educational. The first one was something segfaulting on boot, it happened right after “caching dependencies blablabla”. So I started investigating OpenRC caching and saw segfaults when running /lib/rc/bin/rc-depend -u. So I tried debugging with GDB and hit nothing, even with follow-fork-mode child. Sam suggested me to use strace with -ff -o to get an strace of all children. After grepping it turned out it was lvm2 segfauling because of me having merged an unpatched version from ::gentoo (due to revbump). I knew right away since I had just submitted a runtime segfault patch for lvm2. I also tried debugging with ASan but it turned out ASan was not working with GCC on musl, and for some reason UBSAN was automatically turned on making clang not work either, that was a rabbit hole that we (Sam and me) spent way too much time on hehe. The second issue was caused by me cloning the wrong fork and I spent an unreasonable large amount of time finding out what was wrong.
Continuing next week I’ll work on getting QtWebEngine to work. I’ll also start posting a lot more blog posts, one each day summarizing what I’ve done, and what I’ll do next day. Some posts will also be made when I get “aha-moments” or just finish something non-trivial. I got this suggestion from Blueknight since I currently use the IRC chat as a blog.
I just ordered a PinePhone Pro which I’ll try getting Gentoo musl with Plasma mobile on.
Bye!
[1]: https://github.com/FeralInteractive/gamemode/pull/368
[2]: https://github.com/alfredfo/libexecinfo/tree/meson
[3]: https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
[4]: https://www.openwall.com/lists/musl/2015/04/09/3
[5]: https://github.com/alfredfo/gentoo/commit/9413639d30b2b31c2a64fd2a6c76304e399438b0
[6]: https://www.openwall.com/lists/musl/2014/06/29/4
[7]: https://github.com/void-linux/void-packages/tree/master/srcpkgs/musl-legacy-compat
[8]: https://pkgs.alpinelinux.org/package/edge/community/x86_64/musl-legacy-error