This is the first part of my blog for supporting GNOME desktop on musl profile. I’ll
try to update on weekly basis or post my weekly report here. Since this is
my first post I’ll start with a little bit of introduction.
Introduction
I’m listout ( you can find me on gitlab, github and IRC under this alias ). As
of now, I’m a junior firmware developer at a startup. I’ve been a Linux user for
about 6 years now and a GNOME user for about 3. I took part in Google Summer of
Code 2022 and as a part of that, I’ll be contributing to Gentoo by porting GNOME
for musl profile.
Little bit of what I’ll be doing throughout Google Summer of Code this year
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’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.
What is musl
Before we go any further, I think it will be better if we learned a little bit
more about musl, what it is and how it differs from other libc.
According to Wikipedia, the C standard library or libc is the standard library
for the C programming language, as specified in the ISO C standard. Starting
from the original ANSI C standard, it was developed at the same time as the C
library POSIX specification, which is a superset of it. Since ANSI C was adopted
by the International Organization for Standardization, the C standard library is
also called the ISO C library. [1]
Musl is one such C standard library or libc. Quoting from the musl websites
about section, musl, pronounced like the word “mussel” or “muscle”, is a “libc”,
an implementation of the standard library functionality described in the ISO C
and POSIX standards, plus common extensions, built on top of the Linux system
calls API. While the kernel governs access to hardware, memory, filesystems, and
the privileges for accessing these resources, libc is responsible for:
- providing C bindings for the OS interfaces
- constructing higher-level buffered stdio, memory allocation management, thread
creation and synchronization operations, shared library loading, and so on using
the lower-level interfaces the kernel provides - implementing the pure library routines of the C language like strstr,
snprintf, strtol, exp, sqrt, etc. [2]
There is much more, I’ll link the musl site [2] for any to read further.
Installing GNOME on musl profile for the first time
In my proposal, I decided to dedicate the first two weeks to installing gnome-light
package (meta package) and try to fix/patch any issues that I come across. So I did
that, first on a virtual machine (with advice from blueknight, I decided to go with libvirt)
and then on a separate partition on my laptop. While doing so I came across four
main issues, related to four different packages, namely samba from net-fs, ppp
from net-dialup, gnome-terminal from x11-terms, and last but not the least
librsvg from gnome-base. I’ll go through the issues in more detail in the next
few sections, but as a tl;dr I was able to get a gnome desktop running on musl
profile.
The issues I came across while installing GNOME on musl profile
As I mentioned above I came across four main issues while installing GNOME on musl profile. I’ve gone over them one by one in this section.
net-fs/samba
On musl few defines are not available, whereas they are on Glibc. NETDB_INTERNAL and NETDB_SUCCESS 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 nsswitch/wins.c of the samba source.
Example patch
diff --git a/nsswitch/wins.c b/nss/patch any issues that I come across. So I didwitch/wins.c index e202a45..a310477 100644 --- a/nsswitch/wins.c +++ b/nsswitch/wins.c @@ -40,6 +40,14 @@ static pthread_mutex_t wins_nss_mutex = PTHREAD_MUTEX_INITIALIZER; #define INADDRSZ 4 #endif +#ifndef NETDB_INTERNAL +#define NETDB_INTERNAL -1 +#endif + +#ifndef NETDB_SUCCESS +#define NETDB_SUCCESS 0 +#endif + _PUBLIC_ON_LINUX_ NSS_STATUS _nss_wins_gethostbyname_r(const char *hostname, struct hostent *he,
net-dialup/ppp
ppp’s issue was that Glibc provides a header file named <net/ppp_defs.h> whereas musl doesn’t. So I initially thought that maybe using <linux/ppp_defs.h> would help since it would almost always be available and we wouldn’t have to depend on libc. But unfortunately, it didn’t work, but I’ll come back to this package later and fix it as it’s needed by GNOME. I’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’ve got very valuable advice regarding this issue from blueness on my weekly report [4] and I’ll try to implement them this week.
x11-terms/gnome-terminal
gnome-terminal’s issue was similar to samba’s issue, that is missing defines which are present on Glibc whereas missing on musl. In this particular case, the missing defines were W_EXITCODE . So I just had to add that define (if already not defined) in the file terminal.cc, of gnome-terminal’s source.
Example patch
diff --git a/src/terminal.cc b/src/terminal.cc
index 27ee91e..5f4d880 100644
--- a/src/terminal.cc
+++ b/src/terminal.cc
@@ -47,6 +47,11 @@
GS_DEFINE_CLEANUP_FUNCTION0(TerminalOptions*, gs_local_options_free, terminal_options_free)
#define gs_free_options __attribute__ ((cleanup(gs_local_options_free)))
+/* fix for musl */
+#ifndef W_EXITCODE
+#define W_EXITCODE(ret, sig) ((ret) << 8 | (sig))
+#endif
+
/* Wait-for-exit helper */
typedef struct {
gnome-base/librsvg
We discovered this issue while trying to get a gnome-shell running, as upon boot I would get a white screen with text saying “Oh no. Something has gone wrong” 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.
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’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 gfile by invoking the g_file_get_uri it would just result in a segmentation fault as well. We (specifically another fellow GSoC 22 student Catcream) found a similar issue on librsvg’s GitLab issues page. The solution mentioned there was to try increasing the stack size of librsvg as musl has had issues with it’s stack size before due to it being small compared to glibc. So we decided to try that, and that solution didn’t work unfortunately. We decided to call it there, and just use a older (not rustified 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.
With that my first week of Google Summer of Code at Gentoo ended. However there the librsvg was still bugging me.
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].
End of week 1
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’t been able to test the patches using Gentoo’s test suites, the librsvg issue needs further narrowing down, why does it work when increasing the stack size of gnome-shell. We’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.
Anyways, I’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.
I apologize for being vague in my process of debugging the gnome-shell issue using gdb, I’ll probably create a separate post about that or update this post later. Also feel free to suggest edits.
listout, over and out.
[1]: https://en.wikipedia.org/wiki/C_standard_library
[2]: https://musl.libc.org/about.html
[3]: https://github.com/ppp-project/ppp/issues/351
[4]: https://archives.gentoo.org/gentoo-soc/message/0613db687f633fb310583486bdd9fdb0