From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 305D7158094 for ; Sun, 10 Jul 2022 22:25:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F34BE0C2F; Sun, 10 Jul 2022 22:25:30 +0000 (UTC) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C51D1E0C2F for ; Sun, 10 Jul 2022 22:25:29 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id EB028106015E for ; Sun, 10 Jul 2022 22:25:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1657491927; s=s1; d=catcream.org; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=0k91BOAEMkv4Pege064YWv5pkrO2vCloqL2EIIG0Xok=; b=ZRXZxjLVjfxloC4Sp1Wfh7dJ2O3J2XLpGZJBvkV8+ydxD0uS/8cDhHXKI2WTRh0I GG2uohCnGIyMO6fY4EpMId4HM3qu+WhIdWBLw5kWVRbHNml+QHlNBWa5JQQ4x3RqTkV r5EpCyFVaD42ntfq9s8EdpdgF/0Z5DCs1g0plA5AHpIQQ5thX8rVysi9ZakNSfaH6B4 /d1ffKcC54wsHw3mV4bW2UjSH4itSMEhFqNKW3SMMJt53+qS0YKf9knz/WZVFot12Ly mjtrFYxfIX+ZEzaxwhlbbwLCCv/diAHFPZwrYt5lrBDg8oCFAbbLZpF+ByumOdlW4Tz PE3FmdG/ag== Date: Mon, 11 Jul 2022 00:25:27 +0200 (CEST) From: cat@catcream.org To: Gentoo Soc Message-ID: Subject: [gentoo-soc] GSoC report week 4. Musl support for Qt/KDE Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b5c41f3c-6dd3-48f9-b843-beaa3022b772 X-Archives-Hash: 53dfa22fe3b19754277cfe2c5cb41a63 Hi! This is my weekly report for week 4 of Summer of Code. This week I've d= one some more ebuild development and fixed some more build-time bugs for va= rious packages. 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 Ste= am and Lutris. I also tried some native gaming with Super Tux Kart, Super T= ux, and fheroes2. This was on the weekend but I still think it's worth ment= ioning 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 func= tions 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 j= ust installing it does not solve every problem because some programs incorr= ectly 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 st= ory with sci-libs/metis, but that just assumed execinfo symbols were provid= ed bu glibc unconditionally. What they should be doing is searcing for exec= info symbols with AC_SEARCH_LIBS (autotools) or similar for other build sys= tems. 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 Sa= m 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 fa= lse because QMake is being phased out for CMake and we thought it wasn't wo= rth spending time properly patching it upstream. My personal favorite solut= ion is to just use GDB :). Another thing worth discussing is the addition of more *-standalone librari= es for Gentoo musl. A problem which both me and listout run into a lot is e= rror.h not being defined. Rich, the maintainer of musl suggests that [6] ad= ding 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 w= e'll need to patch every application to do that, and even then it's not a p= retty solution. Ideally we want all applications to use standards-defined m= ethod 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 erro= r.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/catc= ream_repo/blob/master/sys-libs/musl-compat-error/musl-compat-error-1.0.0.eb= uild. plocate is an example of a package that used error.h and I patched th= at with fprintf + exit this week. I also spent a lot time fixing two non-issues, but "fixing" the first one w= as very educational. The first one was something segfaulting on boot, it ha= ppened right after "caching dependencies blablabla". So I started investiga= ting 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 c= lang 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 st= art 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-mo= ments" or just finish something non-trivial. I got this suggestion from Blu= eknight since I currently use the IRC chat as a blog. I just ordered a PinePhone Pro which I'll try getting Gentoo musl with Plas= ma 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/9413639d30b2b31c2a64fd2a6c76= 304e399438b0 [6]: https://www.openwall.com/lists/musl/2014/06/29/4 [7]: https://github.com/void-linux/void-packages/tree/master/srcpkgs/musl-l= egacy-compat [8]: https://pkgs.alpinelinux.org/package/edge/community/x86_64/musl-legacy= -error