{"id":18,"date":"2022-06-20T19:38:32","date_gmt":"2022-06-20T19:38:32","guid":{"rendered":"https:\/\/blogs.gentoo.org\/gsoc\/?p=18"},"modified":"2022-07-08T14:52:49","modified_gmt":"2022-07-08T14:52:49","slug":"musl-support-expansion-for-supporting-gnome-desktop-on-gentoo","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/gsoc\/2022\/06\/20\/musl-support-expansion-for-supporting-gnome-desktop-on-gentoo\/","title":{"rendered":"Musl support expansion for supporting GNOME desktop"},"content":{"rendered":"<p>This is the first part of my blog for supporting GNOME desktop on musl profile. I&#8217;ll<br \/>\ntry to update on weekly basis or post my weekly report here. Since this is<br \/>\nmy first post I&#8217;ll start with a little bit of introduction.<\/p>\n<p><strong>Introduction<\/strong><\/p>\n<p>I&#8217;m listout ( you can find me on gitlab, github and IRC under this alias ). As<br \/>\nof now, I&#8217;m a junior firmware developer at a startup. I&#8217;ve been a Linux user for<br \/>\nabout 6 years now and a GNOME user for about 3. I took part in Google Summer of<br \/>\nCode 2022 and as a part of that, I&#8217;ll be contributing to Gentoo by porting GNOME<br \/>\nfor musl profile.<\/p>\n<p><!--more--><\/p>\n<p><strong>Little bit of what I&#8217;ll be doing throughout Google Summer of Code this year<\/strong><\/p>\n<p>My main idea for Google Summer of Code is to port GNOME desktop to work on a musl profile. However, there are a few side ideas, like killing ::musl (gentoo&#8217;s musl specific repository) completely. There is also work being done to port KDE desktop on musl. Few other Linux distributions have already been able to achieve this before, namely Alpine Linux and Void Linux, so with this project complete one would expect to have GNOME running both on Glibc and musl thus giving users further choice for building their Gentoo system.<\/p>\n<p><strong>What is musl<\/strong><\/p>\n<p>Before we go any further, I think it will be better if we learned a little bit<br \/>\nmore about musl, what it is and how it differs from other libc.<\/p>\n<p>According to Wikipedia, the C standard library or libc is the standard library<br \/>\nfor the C programming language, as specified in the ISO C standard. Starting<br \/>\nfrom the original ANSI C standard, it was developed at the same time as the C<br \/>\nlibrary POSIX specification, which is a superset of it. Since ANSI C was adopted<br \/>\nby the International Organization for Standardization, the C standard library is<br \/>\nalso called the ISO C library. [1]<\/p>\n<p>Musl is one such C standard library or libc. Quoting from the musl websites<br \/>\nabout section, musl, pronounced like the word &#8220;mussel&#8221; or &#8220;muscle&#8221;, is a &#8220;libc&#8221;,<br \/>\nan implementation of the standard library functionality described in the ISO C<br \/>\nand POSIX standards, plus common extensions, built on top of the Linux system<br \/>\ncalls API. While the kernel governs access to hardware, memory, filesystems, and<br \/>\nthe privileges for accessing these resources, libc is responsible for:<\/p>\n<ul>\n<li>providing C bindings for the OS interfaces<\/li>\n<li>constructing higher-level buffered stdio, memory allocation management, thread<br \/>\ncreation and synchronization operations, shared library loading, and so on using<br \/>\nthe lower-level interfaces the kernel provides<\/li>\n<li>implementing the pure library routines of the C language like strstr,<br \/>\nsnprintf, strtol, exp, sqrt, etc. [2]<\/li>\n<\/ul>\n<p>There is much more, I&#8217;ll link the musl site [2] for any to read further.<\/p>\n<p><strong>Installing GNOME on musl profile for the first time<br \/>\n<\/strong><\/p>\n<p>In my proposal, I decided to dedicate the first two weeks to installing gnome-light<br \/>\npackage (meta package) and try to fix\/patch any issues that I come across. So I did<br \/>\nthat, first on a virtual machine (with advice from blueknight, I decided to go with libvirt)<br \/>\nand then on a separate partition on my laptop. While doing so I came across four<br \/>\nmain issues, related to four different packages, namely samba from net-fs, ppp<br \/>\nfrom net-dialup, gnome-terminal from x11-terms, and last but not the least<br \/>\nlibrsvg from gnome-base. I&#8217;ll go through the issues in more detail in the next<br \/>\nfew sections, but as a tl;dr I was able to get a gnome desktop running on musl<br \/>\nprofile.<\/p>\n<p><strong>The issues I came across while installing GNOME on musl profile<\/strong><\/p>\n<p>As I mentioned above I came across four main issues while installing GNOME on musl profile. I&#8217;ve gone over them one by one in this section.<\/p>\n<h3>net-fs\/samba<\/h3>\n<p>On musl few defines are not available, whereas they are on Glibc. <strong>NETDB_INTERNAL<\/strong> and <strong><span class=\"blob-code-inner blob-code-marker js-code-nav-pass \" data-code-marker=\"+\"><span class=\"pl-mi1\">NETDB_SUCCESS<\/span><\/span> <\/strong>are two such defines, due to which while building samba one would an error message of these defines missing and the build would fail. The solution was to check if they are not defined and add them in <span class=\"blob-code-inner blob-code-marker js-code-nav-pass \" data-code-marker=\"+\"><span class=\"pl-md\">nsswitch\/wins.c<\/span><\/span> of the samba source.<\/p>\n<p>Example patch<\/p>\n<pre>diff --git a\/nsswitch\/wins.c b\/nss\/patch any issues that I come across. So I didwitch\/wins.c\r\nindex e202a45..a310477 100644\r\n--- a\/nsswitch\/wins.c\r\n+++ b\/nsswitch\/wins.c\r\n@@ -40,6 +40,14 @@ static pthread_mutex_t wins_nss_mutex = PTHREAD_MUTEX_INITIALIZER;\r\n #define INADDRSZ 4\r\n #endif\r\n \r\n+#ifndef NETDB_INTERNAL\r\n+#define NETDB_INTERNAL -1\r\n+#endif\r\n+\r\n+#ifndef NETDB_SUCCESS\r\n+#define NETDB_SUCCESS 0\r\n+#endif\r\n+\r\n _PUBLIC_ON_LINUX_\r\n NSS_STATUS _nss_wins_gethostbyname_r(const char *hostname, struct hostent *he,\r\n<\/pre>\n<h3>net-dialup\/ppp<\/h3>\n<p>ppp&#8217;s issue was that Glibc provides a header file named &lt;net\/ppp_defs.h&gt; whereas musl doesn&#8217;t. So I initially thought that maybe using &lt;linux\/ppp_defs.h&gt; would help since it would almost always be available and we wouldn&#8217;t have to depend on libc. But unfortunately, it didn&#8217;t work, but I&#8217;ll come back to this package later and fix it as it&#8217;s needed by GNOME. I&#8217;ve filed an issue [3] regarding this upstream, and the reply from the maintainer is that they already have a pull request regarding a similar issue that is under review and they are working on making ppp use purely Linux headers. But I&#8217;ve got very valuable advice regarding this issue from <em>blueness<\/em> on my weekly report [4] and I&#8217;ll try to implement them this week.<\/p>\n<h3>x11-terms\/gnome-terminal<\/h3>\n<p>gnome-terminal&#8217;s issue was similar to samba&#8217;s issue, that is missing defines which are present on Glibc whereas missing on musl. In this particular case, the missing defines were <strong><span class=\"js-issue-title markdown-title\">W_EXITCODE <\/span><\/strong><span class=\"js-issue-title markdown-title\">. So I just had to add that define (if already not defined) in the file terminal.cc, of gnome-terminal&#8217;s source.<\/span><span class=\"js-issue-title markdown-title\"><br \/>\n<\/span><\/p>\n<p>Example patch<\/p>\n<pre>diff --git a\/src\/terminal.cc b\/src\/terminal.cc\r\nindex 27ee91e..5f4d880 100644\r\n--- a\/src\/terminal.cc\r\n+++ b\/src\/terminal.cc\r\n@@ -47,6 +47,11 @@\r\n GS_DEFINE_CLEANUP_FUNCTION0(TerminalOptions*, gs_local_options_free, terminal_options_free)\r\n #define gs_free_options __attribute__ ((cleanup(gs_local_options_free)))\r\n \r\n+\/* fix for musl *\/\r\n+#ifndef W_EXITCODE\r\n+#define W_EXITCODE(ret, sig) ((ret) &lt;&lt; 8 | (sig))\r\n+#endif\r\n+\r\n \/* Wait-for-exit helper *\/\r\n \r\n typedef struct {\r\n<\/pre>\n<h3>gnome-base\/librsvg<\/h3>\n<p>We discovered this issue while trying to get a gnome-shell running, as upon boot I would get a white screen with text saying &#8220;Oh no. Something has gone wrong&#8221; with a sad face, GNOME seems to refer to this as a fail whale. The package however built fine while the initial installation, without any sort of warning. We came to the conclusion that librsvg was the issue after debugging the gnome-shell and generating a backtrace.<\/p>\n<p>Coming to the issue itself, it proved to be rather difficult to debug at first, provided it could be due to me being new to debugging and using tools such as gdb and generating and decoding backtraces. Much thanks to my mentor, sam and dilfridge, and Gentoo&#8217;s GNOME lead leio from IRC who helped me set up the right environment and learn the appropriate tools for debugging. So, after setting up the correct environment and learning the debugging tools we found out that the issue seemed to be that librsvg crashed when trying to render a certain SVG. So the next appropriate thing to do would be to find out which SVG was the cause of the crash. That did work either, when we tried to get the file after selecting the appropriate frame and trying to print the <strong>gfile<\/strong> by invoking the <strong>g_file_get_uri <\/strong>it would just result in a segmentation fault as well. We (specifically another fellow GSoC 22 student Catcream) found a similar issue on librsvg&#8217;s GitLab issues page. The solution mentioned there was to try increasing the stack size of librsvg as musl has had issues with it&#8217;s stack size before due to it being small compared to glibc. So we decided to try that, and that solution didn&#8217;t work unfortunately. We decided to call it there, and just use a older (not <em>rustified <\/em>librsvg) and it did work, and we had a gnome desktop on musl. I, with advice from sam_, filed a bug report upstream [5] and called it a week.<\/p>\n<p>With that my first week of Google Summer of Code at Gentoo ended. However there the librsvg was still bugging me.<\/p>\n<p>So on Monday morning the first thing I did was build both gnome-shell and librsvg with increased stack size, not to mention the maintainer of librsvg said the same too, and lo and behold I had a GNOME desktop with latest librsvg and here I am typing this blog from my GNOME desktop on musl [6].<\/p>\n<p><strong>End of week 1<\/strong><\/p>\n<p>So now at the end of week 1 we do have a GNOME desktop running on musl profile but there is still much work to be done. I haven&#8217;t been able to test the patches using Gentoo&#8217;s test suites, the librsvg issue needs further narrowing down, why does it work when increasing the stack size of gnome-shell. We&#8217;re suspecting that increasing the stack size of gnome-shell is increasing the stack size of some other library which was the real reason for the issue. This would probably require me to go through the DEPEND array of the gnome-shell ebuild and try to narrow it down further.<\/p>\n<p>Anyways, I&#8217;ll conclude this post here, with much thanks to my mentor sam_ and dilfridge, leio from the GNOME team and Catcream for reproducing the issue on his end.<\/p>\n<p>I apologize for being vague in my process of debugging the gnome-shell issue using gdb, I&#8217;ll probably create a separate post about that or update this post later. Also feel free to suggest edits.<\/p>\n<p>listout, over and out.<\/p>\n<p>&nbsp;<\/p>\n<p>[1]: <a href=\"https:\/\/en.wikipedia.org\/wiki\/C_standard_library\">https:\/\/en.wikipedia.org\/wiki\/C_standard_library<\/a><\/p>\n<p>[2]:\u00a0<a href=\"https:\/\/musl.libc.org\/about.html\">https:\/\/musl.libc.org\/about.html<\/a><\/p>\n<p>[3]: <a href=\"https:\/\/github.com\/ppp-project\/ppp\/issues\/351\">https:\/\/github.com\/ppp-project\/ppp\/issues\/351<\/a><\/p>\n<p>[4]: <a href=\"https:\/\/archives.gentoo.org\/gentoo-soc\/message\/0613db687f633fb310583486bdd9fdb0\">https:\/\/archives.gentoo.org\/gentoo-soc\/message\/0613db687f633fb310583486bdd9fdb0<\/a><\/p>\n<p>[5]: <a href=\"https:\/\/gitlab.gnome.org\/GNOME\/librsvg\/-\/issues\/874\">https:\/\/gitlab.gnome.org\/GNOME\/librsvg\/-\/issues\/874<\/a><\/p>\n<p>[6]: <a href=\"https:\/\/imgur.com\/a\/JiS1UEA\">https:\/\/imgur.com\/a\/JiS1UEA<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This is the first part of my blog for supporting GNOME desktop on musl profile. I&#8217;ll try to update on weekly basis or post my weekly report here. Since this is my first post I&#8217;ll start with a little bit &hellip; <a href=\"https:\/\/blogs.gentoo.org\/gsoc\/2022\/06\/20\/musl-support-expansion-for-supporting-gnome-desktop-on-gentoo\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":176,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[7],"tags":[11,10,13,12],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/18"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/users\/176"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/comments?post=18"}],"version-history":[{"count":17,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/18\/revisions"}],"predecessor-version":[{"id":67,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/posts\/18\/revisions\/67"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/media?parent=18"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/categories?post=18"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/gsoc\/wp-json\/wp\/v2\/tags?post=18"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}