Thoughts about musl standalone compatibility packages for Gentoo (controversial!)

Thoughts about musl standalone compatibility packages for Gentoo

Hi! With me and listout having plowed through a lot of build time issues with musl libc we have started to face some larger issues and noticed some patterns.

The issue

One of the issues that constantly pop up is error.h not existing.

fatal error: error.h: No such file or directory

Solutions

We have a number of solutions to this issue, with some listed below:

  1. Implement the same functionality using standards-compliant code such as the POSIX fprintf(stderr, …) + exit(status) or C89 perror().
  2. Add a compat/error.h header into the source tree of the package in question, and use it if error.h.
  3. Make the system provide a error.h header file in the standard system include directories.

The most pure solution would obviously be to do 1, but it is also the most time-consuming. It can also require some thinking if the package in question is using the error_message_count and error_one_per_line static global variables.

Solution number 2 is like the first time consuming since you need to individually patch packages, and even worse: we’re not doing it properly. This can be used to annoy upstreams and hopefully make them switch to a musl-compatible way of handling errors.

The third solution is the easiest one, just make a simple ebuild and make packages using error.h depend on it if running musl libc. This can be seen as the worst one as we never inform upstream of their error, and other musl systems will still be affected by it. BUT both Alpine and Void Linux have this, and it saves us a lot of time working on “real” problems. Users of Gentoo musl will also have an easier time by not running into this issue, especially with third party software outside ::gentoo.

Our guy Rich Felker (musl developer) had previously suggested solutions 1 and 2, but probably not from a mass package porting perspective.

Discussions

I here thought that adding compatibility libraries made sense, but I still wanted some confirmations from the seasoned Gentoo developers. So I started off with this reply, which led to #gentoo-proxy-maint. Most people thought it made sense doing it, but some were against to, after discussing, discussing and … discussing Sam came up with this genious idea:

sam_so, a compromise would be, to add it, but still work to kill the deps on it

In effect that’d mean that users of Gentoo musl can just emerge this header never worry about this stuff. It also means that we’ll fix the issues meaning we get the benefits of solution #1. The only downside to this is that we will spend some time fixing the same issue, but properly fixing stuff is a part of this project and should be done!

THE END

This entry was posted in musl KDE. Bookmark the permalink.

Leave a Reply

Your email address will not be published.