{"id":207,"date":"2015-08-04T12:58:04","date_gmt":"2015-08-04T12:58:04","guid":{"rendered":"http:\/\/blogs.gentoo.org\/blueness\/?p=207"},"modified":"2015-08-04T12:58:04","modified_gmt":"2015-08-04T12:58:04","slug":"alt-libc-the-state-of-uclibc-and-musl-in-gentoo-part-1","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/blueness\/2015\/08\/04\/alt-libc-the-state-of-uclibc-and-musl-in-gentoo-part-1\/","title":{"rendered":"alt-libc: The state of uClibc and musl in Gentoo (part 1)"},"content":{"rendered":"

About five years ago, I became interested in alternative C standard libraries<\/a> like uClibc<\/a> and musl<\/a> and their application to more than just embedded systems.\u00a0 Diving into the implementation details of those old familiar C functions can be tedious, but also challenging especially under constraints of size, performance, resource consumption, features and correctness.\u00a0 Yet these details can make a big difference as you can see from this comparison of glibc, uClibc, dietlibc and musl<\/a>.\u00a0 I first encountered libc performance issues when I was doing number crunching work for my ph.d. in physics at Cornell\u00a0 in the late 80’s.\u00a0 I was using IBM RS6000’s (yes!) and had to jump into the assembly.\u00a0 It was lots of fun and I’ve loved this sort of low level stuff ever since.<\/p>\n

Over the past four years, I’ve been working towards producing stage3 tarballs for both uClibc<\/a> and musl<\/a> systems on various arches, and with help from generous contributors (thanks guys!), we now have a pretty good selection on the mirrors.\u00a0 These stages are not strictly speaking embedded in that they do not make use of busybox to provide their base system.\u00a0 Rather, they employ the same packages as our glibc stages and use coreutils, util-linux, net-tools and friends.\u00a0 Except for small details here and there, they only differ from our regular stages in the libc they use.<\/p>\n

If you read my last blog posting on this new release engineering tool I’m developing called GRS<\/a>, you’ll know that I recently hit a milestone in this work.\u00a0 I just released three hardened, fully featured XFCE4 desktop systems for amd64.\u00a0 These systems are identical to each other except for their libc, again modulo a few details here and there.\u00a0 I affectionately dubbed these Bluemoon<\/strong> for glibc, Lilblue<\/strong><\/a> for uClibc, and Bluedragon<\/a><\/strong> for musl.\u00a0 (If you’re curious about the names, read their homepages.)\u00a0 You can grab all three off my dev space<\/a> , or off the mirrors under experimental\/amd64\/{musl,uclibc}<\/a> if you’re looking for just Lilblue or Bluedragon — the glibc system is too boring to merit mirror space.\u00a0 I’ve been maintaining Lilblue for a couple of years now, but with GRS, I can easily maintain all three and its nice to have them for comparison.<\/p>\n

If you play with these systems, don’t expect to be blown away by some amazing differences.\u00a0 They are there and they are noticeable, but they are also subtle.\u00a0 For example, you’re not going to notice code correctness in, say, pthread_cancel() unless you’re coding some application and expect certain behavior but don’t get it because of some bad code in your libc.\u00a0 Rather,\u00a0 the idea here is push the limits of uClibc and musl to see what breaks and then fix it, at least on amd64 for now.\u00a0 Each system includes about 875 packages in the release tarballs, and an extra 5000 or so binpkgs built using GRS.\u00a0 This leads to lots of breakage which I can isolate and address.\u00a0 Often the problem is in the package itself, but occasionally it’s the libc and that’s where the fun begins!\u00a0 I’ve asked Patrick Lauer for some space where I can set up my GRS builds and serve out the binpkgs.\u00a0 Hopefully he’ll be able to set me up with something.\u00a0 I’ll also be able to make the build.log’s available for packages that fail via the web, so that GRS will double as a poor man’s tinderbox.<\/p>\n

In a future article I’ll discuss musl, but in the remainder of this post, I want to highlight some big ticket items we’ve hit in uClibc.\u00a0 I’ve spent a lot of time building up machinery to maintain the stages and desktops, so now I want to focus my attention on fixing the libc problems.\u00a0 The following laundry list is as much a TODO for me as it is for your entertainment.\u00a0 I won’t blame you if you want to skip it.\u00a0 The selection comes from Gentoo’s bugzilla<\/a> and I have yet to compare it to upstream’s bugs<\/a> since I’m sure there’s some overlap.<\/p>\n

Currently there are thirteen uClibc stage3’s being supported:<\/p>\n